An obvious hole in the LEAPSECS discussion to date is any coherent analysis
of the design of the entire civil time system - either today's system or
the system that some seek to replace it with. We have had various good
specific exchanges such as the current DNS notions, but never even the
hint of an end-to-end design that meets the purposes of a single user
community - let alone a design that will meet the needs of the very large
number of communities that any change to the UTC standard will affect.
It has become clear that LEAPSECS is only a peripheral forum to the
leap second debate. One suspects that different factions on the "inside"
of the discussion have been making use of LEAPSECS primarily to formulate
tactics to subvert the desires expressed on the mailing list. Perhaps
it is naive to expect folks to behave otherwise. What is not naive,
however, is an expectation that whatever agenda is being pursued, that
a serious attempt be made to develop a complete and functional system
design that addresses the needs of all affected communities. What is
not naive is the hope that the faction pushing for a major change to
worldwide civil time will invest the correspondingly broad analytical
effort to understand the needs of the various civil time communities,
and the deep design effort to build a system that will maximize the
utility of any new standard for the largest number of communities, and
yes - to invest the relentless effort to educate communities around
the world in *advance* of any planned change.
Tempers on this list have sometimes gotten quite warm. How can it be
otherwise when even the most basic issues vanish into a vast echoing
silence? Can somebody on the inside, for instance, address the question
of retaining the name, "UTC"? Universal Time is a very well understood
concept - at least among my own community, astronomy.
I seriously continue to question whether the ITU-R "owns" UTC. The ITU-R,
rather, simply *manages* the standard concerning how UTC is delivered.
What I don't question, however, is whether the ITU-R owns the concept
of Universal Time. They most certainly do not. Universal Time is not
an idea limited to its "Coordinated" flavor. The entire issue, after
all, is the descrepancy between UTC and UT1. Which brings me back
around to the question of the name.
It is a total nonstarter from my point of view - and the point of view
of the vast majority of the astronomical community, I believe you will
find - to continue to refer to an emasculated, leap-secondless timescale
offset by so many seconds from TAI as "UTC". The very definition of
"Universal Time" is a timescale that is synchronized with the rotation
of the Earth. UTC is one approximation, UT1 is another, UT2 is yet
another. In general, it isn't only astronomers who refer to "Universal
Time" as a synonym for "Greenwich Mean Time".
I won't belabor previous discussions about why general citizens, not
just astronomers, might care that UTC, civil time that is, continue to
approximate GMT. I guarantee that I'm not alone, however, in thinking
that the *name* UTC should continue to be treated like all other
flavors of Universal Time - as such an approximation to GMT.
So, could somebody on the inside please comment on possible alternative
names for the proposed "constant offset from TAI" successor timescale
to UTC? Some hint that a coherent system design is being developed
would also be appreciated - a system design extending from this new
name, through an unambiguous and self-consistent definition, through a
suite of delivery services for appropriate time signals, through
documentation and education programs demonstrating that communities
world wide have been consulted and considered, and on and on to a
precise implementation plan for how and when the precision timing
community at the prodding of the ITU-R intends to introduce this new
standard in a way that avoids triggering a potential Y2K-scale
disaster.
What's in a name? A lot.
Rob Seaman
National Optical Astronomy Observatory
Received on Mon Apr 28 2003 - 10:56:07 PDT
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:54 PDT