[LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

On Wed, Dec 28, 2016 at 10:33 PM, Zefram <zefram at fysh.org> wrote:
> 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.

It specifically does not. It is a 100% uniform radix notion of time.
It pre-supposed a very special notion for that phrase, as I describe
below.

> 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.

That's implementation defined. Most wind up with it meaning the
following second, but since leap seconds do not exist in POSIX, you
cannot use that to infer what the proper time_t for the leap second
should be. POSIX is only kinda sorta like UTC, and muddies the waters
by saying seconds since 1970 GMT/UTC, when it really means 'Number of
atomic seconds since 1972 + 365 * 2 * 86400 minus any positive leap
seconds, plus any negative leap seconds, and the encoding of a leap
second is undefined since we don't really acknowledge they exist.'
They give examples with math that makes this interpretation crystal
clear. Since leap seconds can't exist, you can't posit what would
happen with any API giving you any answer that's required by the
standards. Since it's implementation defined, the interpretation you
give is allowed, but not required. Here "atomic seconds" means "number
of PPS pulses generated by a perfectly ticking and functioning clock
in operation since the epoch with the PPS produced at the top of every
elapsed SI second" btw, which should go without saying, but since it's
a pedantic discussions about standards must be said.

POSIX does not have leap seconds at all. Any and all encoding and
behavior around leap seconds is implementation defined. There are many
good choices to make, and many bad ones, but they are outside the
standard.

> 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.

Yes. As are a number of newly proposed CLOCK types. These both help
and hurt the situation. They help in that they are the first attempts
to try to break free from pure time_t requiring a uniform radix, but
they likely don't go far enough since they aren't universally
implemented, so they aren't universally used, and there's likely still
bugs lurking in the current trial implementations to work out.

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

Older versions of Linux did just this. It was unhelpful enough that it
got changed. Older unix system did do this but it got changed. Sadly,
older systems are still deployed. Nobody today would think this is a
good idea because of the systems that tried to freeze (or almost
freeze) time during the leap second and the problems that were
encountered by it. It's admittedly a stupid way to go, but it is
allowed by the standard and has the nice property that monotonicity
isn't broken, at the expense of a huge, short-term frequency error.

Warner