Re: Accommodating both camps
> It seems clear that we have two camps, or schools of thought, on this
> mailing list:
>
> 1) Those who favour retaining the status quo ante, in which civil time
> is based on UTC and the standard time and frequency stations broadcast
> UTC; and
>
> 2) Those who find it difficult to cope with UTC's leap seconds mechanism
> and which to abolish leap seconds. These people propose abolishing leap
> seconds, thereby causing the offset from UTC (or its renamed
> replacement, TI) to be constant.
>
> I belong to the former camp. I want UTC, leap seconds and all, to
> continue to be broadcast on the standard time and frequency stations,
> and to continue to be used as the reference from which the various civil
> time zones are offset.
>
> I wonder, though, whether those in the other camp would find it
> acceptable to have the standard time and frequency stations not only
> broadcast UTC and DUT1 (= UT1 - UTC, to 0.1 s resolution), but also to
> broadcast DTAI (= TAI - UTC, 1 s resolution)?
>
> DTAI changes infrequently, so it could be broadcast at a rather low data
> rate. Currently all the various one-bit-per-second digital time codes
> from the various standard time and frequency stations have at least one
> or two unassigned (reserved) bits. So one way to broadcast DTAI would to
> be to change that bit or bits once per minute, to broadcast DTAI at a
> one-bit-per-minute rate.
>
> This would provide a backward-compatible way to accommodate all users.
This might be necessary, but it isn't sufficient and wouldn't
accomodate all users. It would be a good start.
Here's why I'm in camp #2:
(1) Nobody counts time in the variable radix that UTC counts time in.
Instead, they rely on 'naive math' and count time based on the
number of seconds since some epoch. As such, leap seconds
represent an irregularity in this scheme. This is the POSIX
time_t problem, and cannot be solved by simply using TAI (posix
time_t is explicitly UTC).
(2) Broadcasting the DTAI as you call it is insufficient. Many
systems aren't connected to such broadcasts (IRIG doesn't provide
it, ntp doesn't really provide it (although that can change),
etc). In addition, even those systems that are attached cannot
run in TAI until they know the current value. In the case of
spares, they can be powered off for months at a time. This
reduces the performance at startup. GPS receivers have this same
problem: if they have been off a while, they don't know the leap
second count so can't recover UTC until the alminac is broadcast.
Waiting several minutes for the number of leap seconds to be
broadcast is not something that users of time systems like. See
#5 below, as a longer lead time for leap seconds would help this
problem.
(3) There appears to be no provision for broadcasting the history of
leap seconds in your proposal. Systems that deal with time need
this information to correctly process times in the past, or to
correctly compute intervals. While the errors from not having it
are small, they can be meaningful to some applications.
(4) The variable radix of utc makes it hard to convert to TAI without
a full leap second table (in the general case), although 'nowish'
times can be computed.
(5) There's no way to know when the next leap second will happen,
unless you are connected to a source of this information. People
well connected to sources of time get this information in enough
time to do something sane. People connected via IRIG get at most
1 minute of warning of an impending leap second (which means that
you can't feed a NTP server from irig w/o a backchannel for leap
second information). Leap seconds are announced so close to the
event that this presents issues for those sites that wish to have
spares. Matters can be complicated by limited internet
connectivity for some installations. This presents operational
problems for those wishing to deploy systems with a life of
multiple years.
(6) Bullitin C, in a machine parsable form along with history, should
be available via the radio broadcasts and the internet in a well
known place that the time keeping authorities publicly and
frequently acknowledge as being canonical. One can find sources
for this information on the net, but it is hard to know of the
long-term commitment to keeping these files in those exact URLs.
(7) Leap seconds are hard to implement. I can tell you from direct,
first-hand implementation experience that even good, smart
programmers get something wrong. It is hard to test real leap
second events in many systems (unless you have a GPS simulator),
so many of the details are gotten wrong despite programmer's best
efforts. The biggest reason for this that I've seen is that many
of the data streams are vaguely documented, or the documentation
assumes that the programmer has deep knowledge of underlying
protocols that isn't called out in the programming manual. An
example of this is when the leap second indicators change on the
data stream. Looking at the manual, one might assume they change
instantaneously from second to second. Experience has shown that
they change when a new alminac is received. We had one bug where
the programmer assumed the former and despite some test
scaffolding that lead us to believe that it would work, this
failed when we went to the GPS simulator.
(8) Leap seconds are everywhere. If you try to run in TAI, you'll
find that your users want to know UTC time at some point, or will
tell you what UTC time it is. Given this, you have to know the
current leap second value to even startup. And you have to be
*SURE* of that value because you can't go back and tweak stuff
after the fact if this value turns out to be wrong. To get
accurate intervals, you have to run in TAI, but users want UTC.
(9) Leap second testing is difficult and expensive. I can tell you
from first hand experience that it is hard to test timing systems
for leap second compliance. It takes a lot of time, effort and
money to do so. GPS simulator time isn't cheap, especially when
you add travel and lodging to the picture. Adding test
scaffolding to one's code takes time and is only partially
effective at finding problems in the upstream data streams.
(10) 99.999% of the people have a +- 2hour from solar time (using
whatever definition) to what the clocks say tolerance. Timezones
and daylight savings time has given people this tolerance. Only a
tiny fraction of the population has a need for what we call UT1
today. Since UTC will fail in the long run anyway (estimates are
~2k years in the future, give or take), it makes sense to
investigate other options that might have a longer shelf life (my
favorite is move the time zones every ~400 years will last about
~4k years, for example). Shouldn't the expense of those users
that actually need UT1 be borne by them rather than by shifting
that expense to others.
#8 I think is the hardest problem of all, although it seems so
simple. The fact of the matter is that people want UTC time, but they
also want intervals that work. This necessarily requires leap second
history, not just the current value.
Warner
Received on Tue Jan 24 2006 - 09:37:43 PST
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:55 PDT