[time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?

[Steve Summit]

Ralph Aichinger wrote:
> TAI would probably be the more logical way to store and do
> calculations with time, only including leap seconds when
> formatting time for human consumption.

Indeed.  Just about everybody I know who's studied this issue
carefully has come to more or less the same conclusion.  It would
work much, much better than UTC -- except we're basically stuck
with UTC.

The wonderful thing about TAI is that since it's truly monotonic,
it is much, much easier to represent and manipulate than is a
discontinuous timescale like UTC.  In fact, you can immediately
see how useful a monotonic timescale is by observing that POSIX
has decreed that UTC is one.  Except of course that it isn't,
which leads to *the* glaringly fundamental but nearly irresolvable
issue when it comes to keeping truly correct time, and in particular
handling leap seconds, on Unix-like operating systems.

> There is a CLOCK_TAI on Linux, but what will happen if I use it
> as my default clock?

First of all, there's no current way of making CLOCK_TAI the
"default clock".  Deep down inside, the primary, master clock on
any Unix or Linux system is supposed to keep UTC.  When you call
clock_gettime to fetch CLOCK_TAI or any of the other times,
they're generally algorithmically derived from the master clock,
i.e. from UTC.

And even given that it's a derived clock, the support for
CLOCK_TAI is, so far as I've been able to investigate it, still
somewhat incomplete.  When the system boots up, it has no way of
knowing what the TAI-UTC offset is, so of course it starts out as 0.
There's a path via which NTP or some other external program can
set it, but I haven't seen an NTP server in the wild that knows
how and is configured to do so.  (I'd love to be proved wrong on
this, though.)  Furthermore, if nothing sets the TAI-UTC offset,
and if a leap second occurs, the kernel blindly increments the
TAI-UTC offset to 1, which is just wrong.

One appealing possibility would be to redefine the kernel's
master clock to be TAI, and to derive all other clocks (including
CLOCK_REALTIME, which is the primary fetchable UTC time) from it.
Again, the big difficulty (besides the amount of rewriting involved)
is the startup sequence.  There's not a good, guaranteed way for
a newly-booted machine to learn what the current TAI time, and
TAI-UTC offset, are.  Just about every scrap of public infrastructure
devoted to timekeeping distributes UTC, not TAI.  (There's much
more that could be said about this; I'll provide some references
at the end.)

And then there's the possibility of *not* rewriting any kernel
code, declaring that it deals in nothing but TAI, and shoving all
the squishy aspects of leap seconds and UTC conversion to user
mode.  But you've still got the startup problem, *and* you've
got the problem that there are several places in the kernel
that actually need proper UTC.  One is so that you can set the
modification timestamps on files correctly.  And I believe there
are a number of other kernel daemons and drivers that need UTC so
that they can properly implement various networking protocols,
such as those involved with streaming video.  (I'm fuzzy on the
details, but I'm reasonably sure those other kernel-level UTC
consumers exist.)

But if you do want to throw caution to the winds, run your kernel
on TAI, and punt the UTC conversion to user mode, there's some
nicely mature code already built in to every Unix and Linux
system that will do most of the work for you, and it's been
around since the 1990s (or maybe even the 1980s, I'm not sure).
This is based on the so-called "right" timezones, which introduce
the TAI-UTC offset when a conversion from time_t to struct tm is
performed, i.e. at the exact same spot that timezone offsets and
DST corrections are applied, which is arguably precisely the
right place to do it.  The requisite leap second tables are part
of the zone files, the same ones that contain all of the timezone
and DST information, and are regularly updated.  You can read
about this at:

	https://www.ucolick.org/~sla/leapsecs/right+gps.html

(Actually, that page describes a variation on the "right" scheme,
using GPS time instead of TAI.)  Unfortunately, virtually no one
uses the "right" zones, in part because of the boot problem, in
part because of the filesystem timestamp problem, and in general
because the scheme basically violates the POSIX standard up,
down, and sideways.

These issues have been discussed at length on, as you can
imagine, the LEAPSECS and TZ lists.  Here are two representative
messages I had handy:

	https://pairlist6.pair.net/pipermail/leapsecs/2016-July/006251.html
	https://mm.icann.org/pipermail/tz/2004-March/012305.html