[LEAPSECS] Time math libraries, UTC to TAI

Brooks Harris brooks at edlmax.com
Wed Dec 28 16:21:55 EST 2016


On 2016-12-28 02:29 PM, Warner Losh wrote:
> 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.
Hi Warner,

My understanding, also from David Wells: "Unlike the POSIX conventions , 
the NTP clock is frozen and does not advanced during the leap second, so 
there is no need to set it back one second at the end of the leap second. "

This seems consistent my understanding of the specs, that POSIX would 
"reset" and NTP would freeze. But POSIX is intentionally vague on its 
definition of "the epoch" to allow some fudge factor for older systems 
to be conformant and somewhat unclear how Leap Seconds are handled.

Indeed some implementations have made different choices, which is 
exactly the sort of mismatched behavior we'd all like to find a way to 
overcome, right?


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

Seems to me these "some are quite good" extensions should be guides to 
adopting and standardizing common deterministic behavior.

-Brooks

> 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
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>



More information about the LEAPSECS mailing list