Re: [LEAPSECS] Longer leap second notice

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Wed, 04 Jan 2006 10:24:52 -0700 (MST)

In message: <2CF8206C-BF90-4C83-9EA3-704386B07048_at_noao.edu>
            Rob Seaman <seaman_at_NOAO.EDU> writes:
: On Jan 3, 2006, at 5:46 PM, Warner Losh wrote:
:
: > As someone who has fought the battles, I can tell you that a simple
: > table is 10x or 100x easier to implement than dealing with parsing
: > the data from N streams. Sure, it limits the lifetime of the
: > device, but a 20 year limit is very reasonable.
:
: Simpler is indeed better - if it satisfies the requirements. While
: we're at it - how about a table to describe worldwide daylight saving
: rules? Oh right - we already have that :-) What we don't have is a
: mechanism to force the U.S. Congress not to change the rules out from
: under us. Retaining the flexibility to easily change the rules is
: one of our requirements.

You are comparing two dissimilar things. A more apt comparison would
be to the leap year rules that we have. We know the rules going
forward a thousand years or so. These too represent the fact that the
oribit arount the earth is not exactly 365.25 days. We add leap
seconds because the rotation of the earth isn't exactly 86400s. The
difference between them is that the earth's rotation around the sun is
more stable than its rotation on its axis.

Daylight savings time is something else entirely. It is a political
decision that sunlight is better used in the evening than the morning.

: Twenty years does seem reasonable. Would suggest this might be
: marketed as an extended cadence maintenance requirement, rather than
: as an expiration date - suspect astronomers aren't the only ones to
: rely on 30 year old computers on occasion. I would heartily agree
: with the notion that a twenty year horizon is about appropriate for
: expecting to reach any decision on the future of UTC. We'd be a lot
: further ahead on this if a closed door decision hadn't been rushed
: for the imagined benefit of the few. In the mean time, there are
: many members of the astronomical software community who would be
: happy to contribute to an effort to improve time handling
: infrastructure and standards, rather than spending their own precious
: time fending off ill conceived political machinations.

Twenty years is an example number. Ideally, as predictive science
gets better, we can do it for longer periods of time. One would hope
to eventually have a schedule that's published 50 or 100 years in
advance. Leap years have been published far in advanced for thousands
of years now, with only one correction to the rule about 700 years ago
as the measurement of the year was refined. As we've refined it
further in the last few hundred years, we know, with a very high
degree of confidence, that the rule is good for at least a thousand
years. The rule isn't perfect, as almost a full day of error can
accumulate in 400 years (requiring an extra leap day), but it does
bound the error nicely.

If we can extend the horizon from 6 months, then that would lead to
better predictibilty of leap seconds, and also allow for better
testing.

Of course, a rule that eliminates them entirely would also fit these
needs, but appears to have little support...

: > If we could have a table for the next 20 years, there'd be no need
: > to even write the code to get from the GPS stream :-)
:
: And if latitude and longitude were engraved on every street corner,
: there would be no need for GPS at all :-) Transport of time signals
: to remote locations is the whole point.

I think it would have been better if I'd stated my point more
directly: Multiple sources of information about leap seconds leads to
a more robust system. GPS can tell us about it, ntpd can tell us
about it, and having a table of known leap seconds can inform us.
These redundant sources of information act as a sanity check. In the
development box that did do the leap second correctly, a backup source
of infomration allowed it to perform correctly over the leap second
despite its development not being complete.

: But should any of us be open to persuasion by a "political tool to
: make the proposal go through without commiting anybody to anything
: for the next couple of hundred of years"?

There are a number of politically expedient quick fixes. Foisting it
off on future generations is a time honored political solution :-(.

: > I find your dismissive attitude towards software professionals that
: > have implemented a complete leap second handling infrastructure,
: > with pluggable sources for leap second rather annoying :-(
:
: Indeed, I'm sure I've exhausted my scant store of good will again.

My statement was born of frustration. It was a little uncalled for.
I regret sending it as it was a cheap shot.

: Would be delighted to hear more about your leap second infrastructure.

In brief, we have a leap second table. This table can be populated
from a number of different sources, usually via a table we've hard
coded into our products. As the products run and discover new leap
seconds, these are added to the table and the table is updated. Since
we parse a number of different data formats to get leap second
information (4 different GPS data types, peeking at the leap indicator
on ntpd, and recovering it from time signal such as Loran), the system
is expandable to allow any source of leap seconds. We've tried to
also deal with the 'cold spares' issues by allowing 'gaps' in the
knowledge of leap seconds, with the understanding that such 'gaps' can
produce incorrect elapsed times when dealing times that fall within
such gaps. I say tried, because we've only been able to do a limited
amount of testing of all the possible 'cold spares' scenarios. We
have a limited ability to update these cold spares once deployed to
the field.

Warner
Received on Wed Jan 04 2006 - 09:26:41 PST