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

[Warner Losh]

On Fri, Dec 30, 2016 at 6:47 PM, Steve Allen <sla at ucolick.org> wrote:
> On Fri 2016-12-30T17:59:14 -0700, Warner Losh hath writ:
>> if you were to transition to a TAI world, then you'd not be able to
>> implement the latter for a TAI time of the UTC time at some
>> Y/M/D/H/M/S past the end of the next six month boundary, since it is
>> impossible to have that knowledge.
>
> This is a well-known problem in the arena of calendaring applications
> when an event is to be attended by parties in many timezones.  The
> calendaring applications must be able to recognize that the timezone
> rules for one or more of those attending can change (sometimes with
> much less notice than the 6 months for leap seconds) between the
> scheduling and the event.  This requires that the event be stored with
> a home time zone (in addition to the time in that zone) in which its
> time is fixed, and that everyone else can be alerted if the local
> authorities announce that home time zone or their own time zone is
> being changed.

Yes. Just so. Keeping all that book is a lot harder than the current
APIs, and many of the kernel interfaces just want a time_t + fraction
to do the scheduling with, leading to an impedance mismatch that's a
friction point where many bugs usually crop up. It's made a bit harder
also by the fact that the current tz code doesn't, by default, stat to
see if the zone data has changed on every time conversion call... It's
even worse here, though, because you do need to convert times between
the different CLOCK_* timescales, and it's hard to know if the
conversion is still valid when you use the converted value. It's
always a race, though thankfully a very slow one... And in the kernel,
there's often an optimized data structure that holds the current
timeouts sorted in order of when the timeouts expire in the kernel's
timescale...

Warner