[LEAPSECS] Time math libraries, UTC to TAI

[Brooks Harris]

On 2017-01-05 09:33 PM, Steve Summit wrote:
> Brooks Harris wrote:
>> It seems to me infeasible to alter the basic behavior of time_t
>> because it effects every aspect of the operating system,
> Absolutely.  Posix time_t is untouchable, and here to stay.
>
>> POSIX time and 86400-second-day systems (including Windows time) will
>> never exactly  match UTC at the Leap Second and we'll have to live
>> with that partial inaccuracy for a long time.
> Right.  (But I don't know if people will find the inevitable
> discrepancies between time_t and "Time2" acceptable.)
That's been at the heart of the "eliminate Leap Seconds debate", right? 
Two camps, basically. But given both UTC with Leap Seconds and Gregorian 
as inevitable conventional circumstances its no longer a question of 
acceptable or not. It is what it is, so lets agree how best to support 
the two with the least inaccuracy, least complexity, and least 
disruption to existing systems. It can't be perfect; the two just do 
not, and will not, match. There's not enough holes in Gregarian to 
accommodate the Leap Second pegs.

>
>> But a second, parallel, time system (call it POSIX Time2) could
>> implement a fixed-epoch timer (call it time2_t) and a
>> Leap-Second-accurate API that would yield YMDhms representation
>> including 23:59:60, call them, for examples, gmtime2() and mktime2().
> That's essentially what clock_gettime(CLOCK_UTC) gets you.
> A struct timespec fetched with clock_gettime(CLOCK_UTC) is your
> "POSIX Time2".  I have implemented gmtime_ts_r() and mktime_ts()
> which operate on struct timespec, and do the right thing with :60.
Ah good.

What source are you using for the Leap Seconds? Tz Database?

>
>> With that, those applications that needed it could use the POSIX Time2
>> API, and everybody else would be none the wiser. It would also define
>> the mapping between legacy POSIX and the UTC-accurate POSIX Time2.
> That's exactly my intent, and I have it all working on my test
> system today.  Just one or two more bugfixes and I should be
> ready to post it!  (I've been saying for the past several months.)
Its a harder problem than it appears, as those of us who've got our 
fingers dirty with the implementation details can attest. Going at it 
directly in the OS takes guts :-)
>
>> Eventually, maybe the file system timestamps could be augmented with
>> flags to mark Leap Second instances and local time parameters.
> I'm not ready to think about the filesystem yet (beyond thinking
> that leapsecond-aware filesystem timestamps don't seem nearly as
> important).
I think the challenge inevitably arrives at the file system(s), so a 
comprehensive plan should anticipate how that could eventually be 
accomplished. This is related to Harlan's "General Timestamp API" 
project, I think.
> First I've got to get non-UTC timers (i.e., almost
> all of them) working properly in the face of smeared time, and
> that's going to be plenty hard, and then some.
Yes, this looks like it could create severe brain damage.

-Brooks

> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>