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

[Warner Losh]

On Sat, Dec 31, 2016 at 1:13 AM, Zefram <zefram at fysh.org> wrote:
> Warner Losh wrote:
>>Other systems don't have this quite yet, but I'd love to see it more
>>widely implemented. Is there a spec for this yet,
>
> https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html

Cool, but last updated 1998...

>>To do this, one would need to tell the kernel that a new leap second
>>is introduced. That's not too bad, but you'd also need to then run
>>through all the timers in the system to adjust the time that the UTC
>>timer was going to fire to be a new time
>
> 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 when
> the timer is set.  Nor does avoiding this imply performing conversion in
> the hot path on timeout.  It suffices that timer settings get converted
> to the operational time scale *sometime* between when they are set and
> when they expire.  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.

>>But I'm curious how you'd represent a leap second in this scheme?
>
> 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. But it certainly suggests some kind of
extensions that might be worth looking into. That suffers from the
conversion problem and the raw-math detection issue still, but it
isn't completely horrible. Is there ongoing work in this area? I
suspect that there'd be about a dozen APIs that might need to grow
awareness of timespecs.

>>          It's especially troublesome if the kernel decides that there
>>really isn't going to be a leap second at midnight for some reason
>
> That would require a decision on what it means to have set a timer for
> a time that doesn't actually exist.  It's not difficult to implement
> any of the reasonable options.

Yes. Generally, the sleep APIs are that you'll sleep for at least that
amount of time. For the timeout api, the absolute time could be fudged
a bit. Thought you'd have an information sharing problem between
userland and the kernel if you wanted a timeout in UTC time
potentially (how do you know that kernel / userland agree on the
future evolution of UTC).

>>            It might be easiest if there's a flag on the UTC timeouts
>>that could be adjusted across such events
>
> Handily, clock_nanosleep() already has a flags parameter that could be
> used for that purpose.

Yea, I was thinking an internal to the kernel's timeout
implementation. If the kernel knows about UTC, then it can do the
conversions, and also trigger on changes to its knowledge of UTC,
which presumably happen infrequently enough to allow the work done in
that case to be somewhat expensive and intrusive to the operation of
the system for the duration of time it takes to do the work.

Warner