[LEAPSECS] Time math libraries, UTC to TAI

[Steve Summit]

Brooks Harris wrote:
> On 2017-01-05 09:33 PM, Steve Summit wrote:
> > Brooks Harris wrote:
> >> 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?

Several.

The kernel can learn of an individual upcoming leap second from
NTP or the like, as it typically does today.  ntpd calls
adjtimex() and sets the STA_INS bit, which triggers the rest of
the leap-second logic.

Also, the kernel has a TAI-UTC table, so it can know if it should
insert a leap second from that.  The table is exposed via a
(root-writable) special file in /proc, making it easy to inspect
and update, without having to introduce new system calls to do so.
On my list of code to write is a user-mode daemon to watch for
new tz files containing leapsec tables and update the kernel's
table if necessary.  Obviously tzdist is a possibility
(eventually a requirement), too.

This is basically the same distinction that Zefram was just
describing in the "Leap seconds ain't broken" thread ("being told
that a leap second has arrived" versus "having advance knowledge
and being able to apply that knowledge at the proper time").

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

Me, I think "not", as I discussed in another message.

> This is related to Harlan's "General Timestamp API" project, I think.

What's that?