Re: Seeking clarifaction of tai64nlocal and leap seconds

Thus said Russ Allbery on Wed, 19 Sep 2012 23:24:49 PDT:

> I'm pretty sure that that's just because there are symmetric errors. I
> think you'd find that the timestamp that's stored is UTC, not TAI, but
> since your  local timezone isn't the  "right" zone, it doesn't  do the
> correction for TAI when converting it back to the human-readable time,
> and so you end up with the right result.

Yes, this is  what I was trying  to imply. Maybe it would  be helpful to
distinguish between a clock that is  running on TAI time and a timestamp
that  is  in  TAI64N  format.  For example,  I  have  one  host  running
clockspeed (which runs  the system clock on TAI).  I have /etc/localtime
linked:

$ ls -l /etc/localtime
lrwxr-xr-x  1 root  wheel  37 Sep 20 07:49 /etc/localtime@ -> /usr/share/zoneinfo/right/US/Mountain

$ ssh host date ; date
Thu Sep 20 07:58:47 MDT 2012
Thu Sep 20 07:58:46 MDT 2012

You can see that as far as the user environment is concerned, the date 
is the same.  But:

$ ssh host date +%s ; date +%s
1348149581
1348149556
$ echo '1348149581 1348149556 -p' | dc
25

So, indeed the UNIX timestamp is  different. All of which means that the
timestamps  are not  portable.  If  your clock  is  on  TAI, then  those
timestamps will have to be adjusted on a non-TAI clock and vice versa.

The fact that a timestamp is in TAI64N format doesn't change this, so we
get:

$ ssh host 'date | tai64n'  | tai64nlocal 
2012-09-20 08:00:58.481122500 Thu Sep 20 08:00:34 MDT 2012

Which  means, for  every host  that  is running  on TAI  time, any  logs
generated that have  not already been converted to  localtime, will need
to be flagged as  having been generated on the TAI  clock. The fact that
it is TAI64N format is not  sufficient to indicate that the timestamp is
in fact from a TAI clock.

Fun stuff.

Andy