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

Zefram zefram at fysh.org
Sat Dec 31 03:13:43 EST 2016


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

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

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

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

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

-zefram


More information about the LEAPSECS mailing list