[LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

On Wed, Dec 28, 2016 at 10:33 AM, Brooks Harris <brooks at edlmax.com> wrote:
> The YMDhms count progression across the first Leap Second
> (1972-06-30T23:59:60 (UTC)) as yielded by POSIX gmtime() is expected to be

Or rather "something like the following," because POSIX doesn't say
what happens during the leap second. Some systems replay the 799
second rather than the 800 second to avoid starting the day twice...
This is also allowed by POSIX because every last thing dealing with
the leap second is implementation defined because it is outside the
scope of the standard. FreeBSD does 799 twice for example. There's
other systems that 'freeze' time during the leap second, only
incrementing it by a tiny fraction for each gettimeofday call.

>  time_t          gmtime()                UTC
> 78796799 = 1972-06-30 23:59:59 = 1972-06-30T23:59:59 (UTC)
> 78796800 = 1972-07-01 00:00:00 = 1972-06-30T23:59:60 (UTC) << Leap Second
> 78796800 = 1972-07-01 00:00:00 = 1972-07-01T00:00:00 (UTC) << time_t reset
> 78796801 = 1972-07-01 00:00:01 = 1972-07-01T00:00:01 (UTC)
>
> time_t must be reset after the Leap Second to maintain the alignment of the
> POSIX and UTC YMDhms representations. In effect the time_t origin has become
> coincident with "1972-01-01 00:00:00 UTC plus one Leap Second", or
> "1972-01-01 00:00:01 UTC". As David Mills says "... In effect, a new
> timescale is reestablished after each new leap second."

Yes, you must repeat time_t values to be posixly correct. Many
extensions to POSIX have been proposed and implemented (and some are
quite good) that effectively say time_t ticks in TAI time and to get
UTC the host must translate with varying degrees of papering over the
old APIs. But Dave Mills is right: if you are trying to count seconds,
your counts are necessarily discontinuous at a leap second in an
implementation defined way.

Warner