[LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

On Thu, Dec 29, 2016 at 12:28 AM, Steve Summit <scs+ls at eskimo.com> wrote:
> If we try to handle them better, two conclusions seem inescapable:
>
> 1. Posix-compatible time_t values will need to be smeared,
>    spreading the leap second out more gradually, to eliminate
>    sudden, unseemly jumps.
>
> 2. There needs to be a well-defined way to deliver true,
>    non-smeared, leapsecond-aware UTC time to code that needs it.
>
> Putting these together, I conclude that any smearing for #1 needs
> to be done in the OS kernel, just before delivering leapsecond-
> unaware Posix-compatible time_t values.  Doing the smearing anywhere
> upstream (as, for example, Google is doing it) precludes #2.
>
> As a proof of concept, I'm working on a set of Linux kernel mods
> to do both #1 and #2.  I had hoped to have them ready for
> interested people to experiment with this Saturday, but
> unfortunately I'm not going to make it.

How do we know when to do #1 and when to do #2? Especially in light of
the uses of #1 that do extra things to get to knowledge of truth? I
think you'd get most cases if you used adj_timex to report the speared
error, since I know of at least some code that recovers UTC from
time_t get time calls this way.

Also, how do you make this work 'by default' without making every
single programmer that uses these APIs know all the leap second rules?

How do you deal with acquiring knowledge of leap seconds after you've
given out 'old' timestamps that might be affected by them? This is
best described as how well you recover from the leapsecond file being
corrupted and replaced, though there's many other scenarios here.

Warner