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

[Warner Losh]

On Fri, Dec 30, 2016 at 5:41 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
>
>> One could imagine having a more complicated structure that could cope with
>> the inherent ambiguity in future times. I can't say "schedule an event
>> exactly 1 year from now" for example without it. I need additional metadata
>> around to know if I want it to happen at the same time of day on the same
>> date or if I want it to happen after than many seconds have elapsed. You
>> can't convert a putative UTC time to TAI time until you are within 6 months
>> of that time (the current announcement schedule) because if you try to
>> compute that time too far in the future, it will change. ...
>
> Could that be solved with 2 functions in the API, one for N seconds from now,
> and a second for at some future date/time specified in Y/M/D/H/M/S format
> rather than something like a time_t?

Only partially (meaning only assuming every day has exactly 86400
seconds). These operations are possible today, since the former is +=
and the latter is timegm(), sorta, but neither groks leap seconds. And
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.  The former, btw, is also done with
timegm, since you can pass it an unnormalized Y/M/D/H/M.S and it will
do the math for you. Except it doesn't deal with leap seconds, since
time_t doesn't. There's too many ways to express these different
items, and different programers make different choices, some less well
suited to a 'tell the right lies' APIs approach than others. Some
programmers rely heavily on timegm and friends, while others try to
roll their own, with varying degrees of competence. Having the rolling
the own bit outside of the library calls is what makes papering over
more difficult.

Warner