Re: Seeking clarifaction of tai64nlocal and leap seconds

Brian Reichert <[email protected]> writes:
> On Wed, Sep 19, 2012 at 02:28:12PM -0700, Russ Allbery wrote:

>> Doesn't that mean that it's (somewhat blindly) assuming that there have
>> been 10 leap seconds since epoch, and will start generating incorrect
>> timestamps as further leap seconds are added?

> Maybe leap seconds only enter into it when you're converting from
> TAI to something human-readable.

That's only sort of true.  The problem is that UTC and TAI differ by leap
seconds, and the time you get from gettimeofday on a UNIX system is
normally in UTC.  So while you don't really notice the problem until you
convert to something human-readable, if you don't adjust for leap seconds,
the timestamp that you write based on gettimeofday is a UTC timestamp, not
a TAI timestamp.  If you ever later treat it like it's a TAI timestamp,
you'll get inaccuracies.

But I'm not completely following the tai64n discussion, since there have
been 25 leap seconds since 1972.  So I'm unclear on where the 10 second
offset is coming from.  Maybe that's what you get if you use the "right"
tables with the tz database?

Hm.  The more I think about it, the more I'm guessing that's the case:
that you only get TAI timestamps from multilog if you've configured your
system clock to be in TAI and are using the "right" tz zone files.

> From the tai64nlocal webpage/manpage:

>        Beware, however, that the current implementation of tai64nlocal
>        relies on the UNIX localtime library routine to find the local
>        time.  Some localtime implementations use a broken time scale
>        that does not account for leap seconds. On systems that use the
>        Olson tz library (with an up-to-date leap-second table), you can
>        fix this problem by setting your time zone to, e.g,
>        right/US/Pacific instead of US/Pacific.

> My Linux distribution indeed has both sets of zone files.  (Java
> does not.)

Sure, but what those files do is adjust for a system clock that's in TAI
so that you still get human-readable times in UTC.  That doesn't help if
you have timestamps that you think are TAI but aren't.

-- 
Russ Allbery ([email protected])             <http://www.eyrie.org/~eagle/>