"Deckers, Michael" wrote on 2001-05-31 10:59 UTC:
> Paul Eggert wrote:
> > Their basic problem is that the UTC timescale is not appropriate for
> > their applications. Their applications would work better with UTS.
> >
> Interesting. Do you mean that UTS should be used as an internal
> timescale in a computer system, or do you propose that UTS is also
> disseminated in some form, may be even as a replacement of UTC?
I proposed UTS really only for use as a standardized time scale within
computer systems (APIs, communication protocols, etc.). Time
dissemination services should continue to broadcast UTC together with an
announcement of when the next leap second will come, from which a
trivial fixed algorithm in every synchronized computer can calculate
UTS. Neither GPS/DCF77/etc. nor the NTP protocol would have to be
modified if UTS were introduced on a broad scale as the time base for
computer systems.
If we used UTS also for time dissemination (e.g., radio broadcasts such
as GPS, WWV, WWVB, MSF, JYA, DCF77, etc.) then this would interfere with
the use of these transmitters as standard frequency references (as the
second ticks and their phase relationship to the carrier would change
during the interpolated 1 kilosecond period at the end of a leap-second
day). I think, that would be a quite bad idea. It would also interfere
with all the navigation, space mission planning, telescope control, etc.
software that uses UTC as input.
Future radio clock receivers might come with a little switch on which
you can choose whether you like to have a UTC or UTS display.
[The only time broadcasting service that should be updated in the light
of UTS is the UK transmitter MSF, which shamefully has no leap second
announcement at the moment. But having that is desirable for reliable
reconstruction of UTC anyway.]
Someone lost in time wrote:
> > > "By UTC convention, the adjustment happens at the end of a calendar day,
> > > just before midnight. Upon reaching 24:00:00 that day, UTC is set
> > > back by 1 s, effectively running again from 23:59:59 to 24:00:00."
I don't like such statements. UTC is a clock with a hh:mm:ss.ssss
display. It is not "adjusted" in any other way than inserting a second
of time labels from an extended range (23:59:60.000 - 23:59:60.999) into
the time scale. Anyone speaking of UTC being "set back" in some way just
demonstrates confused terminology and analogies here. That's not
helpful.
What *does* literally get set back indeed is the POSIX clock and similar
representations, which use by definition the same numeric second counter
value to represent (day D) 23:59:60.xxx and (day D+1) 00:00:00.xxx. That
is obviously unpleasant, as it leads to non-causal timestamps and it is
easy to construct scenarios where this could mess up things in theory
(never heard of a documented real-world problem though except for a
common software bug in some first-generation GLONASS receivers).
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
Received on Thu May 31 2001 - 04:44:29 PDT