[LEAPSECS] Time math libraries, UTC to TAI

[Steve Summit]

Martin Burnicki wrote:
> If we don't look only at the kernel and ntpd, but also consider PTP,
> then there's still the question if if wouldn't be better to let the
> kernel time run on TAI, and derive true and/or smeared UTC from it.

Right.  At first when I was trying to implement CLOCK_UTC, I
lumped it in with the problem of reworking the kernel's internal
clock, but actually, they're separate problems.  Although I
*have* reworked the kernel's internal clock (Linux calls it
'xtime'), it's expensive, and I'm now considering it among other
options, of which there are at least three:

1. Have xtime keep true UTC, as I've been doing so far.  This was
   always my first choice, but it ends up being majorly invasive,
   and I fear the Linux kernel developers will lynch me if I so
   much as mention it.

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.

3. Keep xtime just about the way it is, augmented with a
   well-defined leap-second flag (along the lines of the TIME_OOP
   flag returned by adjtimex) so that CLOCK_UTC can still be
   derived from it with full accuracy.

Number 1 was my strong preference at first, because I very much
wanted a kernel that kept "true UTC" internally, with no kludges
or circumlocutions, and derived everything else from it as
necessary.  But the implementation cost to achieve that wish is
turning out to be very high, so #2 (and even the philosophically
ghastly but nicely expedient #3) are starting to look more
attractive.