- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

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

Date: Fri, 5 Jan 2007 21:14:19 -0700

Tony Finch wrote:

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

*
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:55 PDT
*