Re: Accommodating both camps

From: Warner Losh <imp_at_BSDIMP.COM>
Date: Tue, 24 Jan 2006 10:35:01 -0700 (MST)

> 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

(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.

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