[LEAPSECS] Time math libraries, UTC to TAI

[Martin Burnicki]

Steve Summit wrote (offlist):
> In some ways I agree that running the kernel on TAI would be far
> preferable.  I've shied away from it so as to be able to answer
> the critics who are always worrying about disconnected systems
> that might not have a source of TAI-UTC at boot time, or at all.

If your system time is disciplined via NTP then currently the TAI/UTC
offset may not be available since the default NTP protocol doesn't
provide it.

As said earlier, you can use tzdist, or DNS, or a future NTP extension
field to pass down the UTC/TAI offset to clients.

If your system time is adjusted via PTP then the TAI offset is available
anyway via the protocol, if the grandmaster has been configured correctly.

You can use the adjtimex() call to retrieve the kernel's TAI/UTC offset,
so applications can determine this.

I'd assume that for disconnected systems this doesn't even matter.

If the kernel runs on TAI, but the TAI time isn't synchronized anyway,
and the TAI offset is 0, then the UTC time stored in inodes matches TAI
time on this system, but who cares?

BTW, AFAICS current Linux kernels increment the TAI offset when they
insert a leap second. I wonder if that is appropriate.

Initially, if the kernel's TAI offset has not been set then it is 0, so
callers of adjtimex() can see that the offset has not yet been set.

However, after a leap second the kernel increases the TAI offset to 1,
which *might* suggest to the unexperienced user that the TAI offset is
valid. Some tests showed that you can *not* set the kernel's TAI offset
to 0 via the adjtimex() call. So I think the kernel should increment the
TAI offset value only if it has been set before, i.e. if it isn't 0, to
avoid confusion.
See also the discussion in:
http://bugs.ntp.org/show_bug.cgi?id=2869

Thoughts?

Martin