[LEAPSECS] Time math libraries, UTC to TAI

[Zefram]

Warner Losh wrote:
>Except that it does advance... It plays the second twice, once with
>the pending leap set, and once with it cleared I though.

In practice the flags are not that well behaved.  I see the second played
twice, but the flag change is not synchronised with the jump of the
scalar time value.  In the logs I have, the flag changed about halfway
through the second iteration of the second.  So empirically, the two
seconds cannot be distinguished purely by means of the packet on the wire.

This isn't a big problem for NTP.  By design it's robust against
occasional lost packets, so just dropping the ambiguous packets is an
adequate workaround.

>POSIX is silent on leap seconds.

Not if one takes the definition of "seconds since the epoch" seriously.
During a leap second tm_sec would be 60.  The defining expression is
perfectly well defined in these circumstances, and the definition doesn't
say that it *doesn't* apply during a leap second.  (The hedging clauses
are all about not requiring the clock to be accurate; they don't hedge
about what the clock reading means.)  So ostensibly the leap second
is represented by a time_t value indistinguishable from that for the
*following* second.

Of course, in practice this implication gets ignored by NTP-disciplined
kernel clocks.  They tend to follow NTP behaviour for the scalar value
(though older Linux versions used to repeat an unaligned second, not
quite matching the NTP behaviour).  Fortunately, the flags supplied by
adjtimex(2) *are* sufficient to disambiguate, regardless of which second
gets repeated in the time_t.

I have never seen a system that froze the clock.  That would be most
unhelpful behaviour, making it impossible to recover true UTC.

-zefram