Re: [LEAPSECS] Introduction of long term scheduling

From: Rob Seaman <seaman_at_noao.edu>
Date: Fri, 5 Jan 2007 21:14:19 -0700

Tony Finch wrote:

> you need to be able to manipulate representations of times other
> than the present, so you need a full leap second table.

Which raises the question of how concisely one can express a leap
second table. Leap second tables are simply a list of dates - in ISO
8601 or MJD formats, for example. Additionally you need an
expiration date. An ISO string is really overkill, MJD can fit into
an unsigned short for the next few decades - but this is really more
than you need for the current standard since not all MJDs are
permitted, only once per month. Also, we don't need to express leap
seconds that are already known (or never existed), so there is a
useless bias of ~54000 days. If we start counting months now, a
short integer will suffice to encode each leap second for the next
5000+ years - certainly past the point when monthly scheduling will
no longer suffice.

So, let's see - assume:

        1) all 20th century leap seconds can be statically linked
        2) start counting months at 2000-01-31

We're seeing about 7 leapseconds per decade on average, round up to
10 to allow for a few decades worth of quadratic acceleration (less
important for the next couple of centuries than geophysical noise).
So 100 short integers should suffice for the next century and a
kilobyte likely for the next 500 years. Add one short for the
expiration date, and a zero short word for an end of record stopper
and distribute it as a variable length record - quite terse for the
next few decades. The current table would be six bytes (suggest
network byte order):

        0042 003C 0000

A particular application only needs to read the first few entries it
doesn't already have cached - scan backwards through the list just
until you pass the previous expiration date. Could elaborate with a
checksum, certificate based signature or other provenance - but these
apply whatever the representation.

To emphasize a recent point: DUT1 is currently negligible for many
applications. Which is the same thing as saying that the simple
table of quantized leap seconds is quite sufficient for civil
purposes. The effect of the ALHP is to inflate the importance of
DUT1 - not just for "professional" purposes, but for some list of
civil purposes that have yet to be inventoried, e.g., tide tables,
weather forecasts, pointing satellite dishes, aligning sundials (see
article in the Jan 2007 Smithsonian), navigation, aviation, amateur
astronomy, whatever. I'm not arguing here that these are
intrinsically sufficient to justify retaining leap seconds (although
I believe this to be the case). Rather, I'm arguing that even under
a "caves of steel" scenario of Homo sapiens inter-breeding with
Condylura cristata, that there will be applications that require a
explicit DUT1 correction - applications that currently can ignore
this step since UTC is guaranteed to remain within 0.9s of GMT.

So the current requirement is merely to convey a few extra bytes of
state with a six month update cadence. This suffices to tie civil
epochs (and a useful approximation of Earth orientation) to civil
intervals.

The requirement in the post-leap-second Mad Max future, however,
would be to convey some similar data structure representing a table
of DUT1 tie points accurate to some level of precision with some as-
yet-unspecified cadencing requirement. The most natural way to
express this might be the nearest round month to when each integral
step in DUT1 occurs, but it should be clear that the requirement for
maintaining and conveying a table of leap seconds is not eliminated,
but rather transmogrified into a similar requirement to maintain and
convey a table of DUT1 values.

Rob Seaman
NOAO
Received on Fri Jan 05 2007 - 20:14:38 PST