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