[time-nuts] Re: UTC - A Cautionary Tale
M. Warner Losh
imp at bsdimp.com
Tue Jul 19 10:58:48 EDT 2005
In message: <20050719105613.47749a7a.obyrne at iol.ie>
"Chris O'Byrne" <obyrne at iol.ie> writes:
: > >Yes. Leap seconds are absurd enough, leap hours are 3,600 times more
: > >absurd!
: > You forgot to extrapolate that statement to leap days.
: Leap days are extrapolatable for the next 1,000 years at least. There
: are very simple, precise, integer arithmetic algorithms for dealing with
: leap days. There are no such algorithms, and cannot be any such
: algorithms, for leap seconds.
OK. For leap years, we know from 1500ish until ~4000 (assuming they
change it) the rule will be:
if (y % 4 == 0) && (y % 100 != 0 || y % 400 == 0))
This gives a mean year that's very close to the actual mean year. By
not having a leap year in the year 4000, 8000, etc, I believe that it
arrives at an even close answer, but that hasn't been promulgated as a
Give me something like that for leap seconds and I'll be happy.
Note, we don't try to constantly adjust each year by having 1/4 of a
leap day every year to keep things within a 1/2 of day. By the forth
year, we're almsot a full day off, and we accept this as the cost of
doing business without so much as a second thought. We don't worry
that each year we accumulate a little bit of error that means 1 year
in a hundered (typically) we have to omit a day. We should do
something similar with leap seconds. The number of people that care
that DUT1 is off by more than 0.5 is tiny. DUT1 can be as much as a
half minute off and lots of people won't know and won't care.
Astronomers are already applying offsets in lookup form, so they can
easily cope with a larger variation. If we can predict what the
earth's rotation will do over the next 10 or 100 years, we should
schedule leap seconds *NOW* so that we come up with the right answer
at the end of that time. Sure, DUT1 may wander more than a second
off, but I can't believe that we don't possess the ability to be
within 10s during the next 100 years. That's a lot better than just
letting it drift, and it gives good determanism to those programs that
might not have access to leap second information once they are
deployed. It also bounds DUT1 to a value that is still somewhat
useful to all but the most demanding of users with the benefit that
most users won't care and will be able to implement their time systems
more cheaply. Compromise is necessary here, and extremists on both
sides are likely to be disappointed.
As someone who has actually implemented many systems based on TAI, I
can tell you that you *MUST* know about *ALL* leap seconds in order to
implement things using TAI correctly. Nobody directly distributes
TAI, and users want times displayed in UTC. Leap seconds cause lots
of problems, especially when devices are turned off for long periods
of time and leap seconds happen in the interrum (think spares that sit
on the shelf for years). Their randomness needlessly complicates
things. Having them gone, or replaced by a schedule announced years
in advance will help greatly.
Most people can easily tolerate standard midnight being as much as 30
minutes off from local midnight and not have it bother them. Surely
most people can tolerate a world where DUT1 is bounded to 10s rather
than 1s, and those that can't can get corrections.
More information about the time-nuts