Re: [LEAPSECS] Mechanism to provide tai-utc.dat locally

From: Zefram <zefram_at_FYSH.ORG>
Date: Mon, 25 Dec 2006 12:46:29 +0000

Ashley Yakeley wrote:
>This has led me to consider run-time methods of obtaining leap-second
>information,

In the Perl module Time::UTC, I download the table as required from
<http://maia.usno.navy.mil/ser7/tai-utc.dat>. Because this file doesn't
explicitly indicate the end of applicability of the last offset, a
useful end date can only be determined implicitly, by assuming that the
file will be updated at least N weeks in advance of each leap second.
(I use a conservative N = 7.) With this mechanism the file that is
consulted has to be fresh, straight from USNO, so local storage of this
file wouldn't be useful.

The table at <ftp://time.nist.gov/pub/leap-seconds.list> has an explicit
expiry date. (I'm going to make Time::UTC use this at some point.)
Local caching of this file would be possible. I don't think you can
rely on it being locally available, though. Local copies of changing
data tend to get out of date. You'd have to be prepared to download
the file from NIST in case the local copy is stale. (That also lets
you handle systems that don't have a local copy at all.)

Systems that have no Internet connection are more difficult to handle.
Your suggestion of a well-known filesystem location for a leap second
table would be useful here. Of course, you're at the mercy of the
sysadmin wrt keeping the table up to date.

I suggest that you propose a well-known location for an admin-updated copy
of leap-seconds.list (not tai-utc.dat, for the reason explained above).
Then, in your application, have code both to use the local table and
to download the current table from NIST. You'd download if the local
copy is missing or corrupted or doesn't extend as far into the future
as you'd like. You could also maintain an application-specific cache of
the downloaded table, to avoid multiple downloads if the admin-supplied
local copy is inadequate. (Attempting to share a user-updated cache
between users is fraught with peril; just accept that there will be
multiple caches.)

Unfortunately this does involve quite a bit of mechanism in the
application. But that's what libraries are for.

-zefram
Received on Mon Dec 25 2006 - 04:46:55 PST

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