[LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

On Wed, Jan 4, 2017 at 7:15 PM, Steve Summit <scs+ls at eskimo.com> wrote:
> 2. Have xtime keep TAI.  This has the advantage that it's not at
>    all wrong or kludgey to represent TAI as a simple count of
>    seconds since the epoch, which of course xtime already is.
>    The objection, as mentioned here pretty regularly, is that if
>    you want to be able to set the clock from UTC, and deliver
>    UTC, you always need to know TAI-UTC, so if you don't have it
>    (if you're not on the net, or if you don't faithfully receive
>    it early enough during boot) you're sunk.  But I'm now
>    thinking that the work involved in assuming TAI-UTC=0 in that
>    case (and remembering that we can't, for example, return
>    success if someone asks for clock_gettime(CLOCK_TAI), and
>    remembering to fiddle things if we learn TAI-UTC later) may
>    end up being less than the work involved in #1.

The problem here, not listed, is with external stuff. When I touch a
file, the time needs to be stored in UTC time so TAI needs to be
converted to UTC and back again when dealing with files on disk. NFS
needs to report the right time, etc. Times will be off, and there will
be a lot of opportunities for bugs in the conversion. Some filesystems
have this as an explicit requirement, while others have it implicit.
While this would solve the ticking through a leap second problem,
there's a host of other issues hiding behind the scenes.

It then becomes an interesting question: do you have to back convert
form UTC to TAI when doing a stat on a file in this scheme? If so,
then the kernel needs to have a complete and accurate table of leap
seconds to do that conversion back and forth. Where does this come
from? How do you keep it up to date? Is there a locking protocol for
this?

Warner