[LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

[Steve Summit]

Warner Losh wrote:
> On Sat, Dec 31, 2016 at 1:13 AM, Zefram <zefram at fysh.org> wrote:
> > You're prejudging the implementation too much.  The kernel does need
> > to know about each leap second by the time it happens, but it does not
> > need to convert timer expirations between TAI and UTC immediately...
> > If a timer is set to expire a year hence, it would not be difficult
> > to postpone the conversion until a few minutes before it expires, by
> > which time one can expect to be able to perform the conversion correctly.
>
> True. I'd assumed that the kernel has one callout wheel, that wheel is
> in a uniform time scale, and that any conversion would need to be done
> at insertion time. The issue with your suggested approach is how do
> you know when to convert? Do you have a second callout wheel for
> things '> minutes' in the future that gets scanned periodically for
> adjustments? How does that complicate the locking and/or code paths
> for timer cancellation, etc. Too much time being paranoid about making
> change to that code in one specific system I guess.

There is, I fear, a lot of work to be done here to get everything
right.  I'm imagining multiple wheels, but I haven't gotten into
it deeply enough yet to know whether that's feasible.

> > CLOCK_UTC is defined to use 1e9 <= tv_nsec < 2e9 in struct timespec,
> > by implication with tv_sec the same as it is for the preceding second.
>
> Kinky. Won't work with timegm(), et al, since they don't time a
> timespec to do their thing...  Is there ongoing work in this area?

I've implemented localtime, gmtime, mktime, and timegm variants
that take timespecs.  (Actually, I've implemented them all twice,
once for tzcode and once for glibc.)

> I suspect that there'd be about a dozen APIs that might need to grow
> awareness of timespecs.

And despite my reluctance to introduce new data structures,
there's a temptation to introduce a tagged timespec variant that
carries along its clockid.