Re: Mechanism to provide tai-utc.dat locally

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Sun, 24 Dec 2006 23:45:39 -0700 (MST)

In message: <B5D59A2A-47B1-46A2-8EF4-0BE8EC242D2C_at_semantic.org>
            Ashley Yakeley <ashley_at_SEMANTIC.ORG> writes:
: Hello, I just joined the leap seconds list. I wrote the "time"
: package for the Haskell programming language.
: <http://semantic.org/TimeLib/>
:
: I include code for making conversions between TAI and UTC, given a
: leap-second table. I also include code for parsing a tai-utc.dat file
: into a leap-second table. I do not, however, simply include a leap-
: second table as any program compiled with one would be out of date
: after six months.
:
: This has led me to consider run-time methods of obtaining leap-second
: information, and how that might be standardised for use by software
: authors. For instance, I imagine a software package that established
: a well-known place in the directory hierarchy to find tai-utc.dat and
: perhaps other "earth data" files, and was responsible for keeping
: them up to date. Other software could then make use of the package
: without each having to implement their own mechanism.
:
: Does this strike people as worthwhile? Does anyone know of an
: existing effort along these lines?

One can find the leap data from NIST that's up to date:
        ftp://time.nist.org/leap-seconds.list
I believe that there are other places for this information as well.

The problem is that often times one has systems that aren't guarnateed
to be connected to the internet, but are connected to GPS so that this
number can be obtained. Other problems arise from systems that are
intermittently operational (like in sparing situations) that may be
off over many leap seconds...

Warner
Received on Sun Dec 24 2006 - 22:48:51 PST

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