[LEAPSECS] Running on TAI

[Steve Summit]

Martin Burnicki wrote:
> Just a few general thoughts based on an internal note...

And some very good points they were.

> ...The same applies to the time_t type, IMO. If you let the system kernel
> run on TAI or whatever then the time() function still returns a time_t
> data type, but its value represents TAI or whatever has been configured.

Right... but you may or may not be skating on thin ice!

I think the question of "Must time_t represent UTC?" can be
a pretty illuminating one, and it cuts across several of the
fundamental issues here.  Strictly speaking, the Posix definition
of time_t is, as Warner Losh has argued, very specifically UTC.
(And of course it's also a very specifically non-UTC form of UTC.)
But it's equally true, as Gary Miller and Martin have argued,
that in practice people use time_t for all sorts of other things...
but I think we can also agree that (some of the time, at least)
this can lead to additional real confusion, precisely because it
breaks the spec, precisely because doing so may clash with someone
else's spec-based assumptions.

But the real tragedy is that UTC is the timescale that time_t is
the *worst* at representing, precisely because time_t is a uniform
count of seconds since an epoch, and UTC is nonuniform.  Anyone
who tries to "fix" some time_t-using software to do UTC "properly"
is doomed to failure.  At best they'll end up reinventing TAI.

To my mind, a pretty good litmus test for how good an alleged
scheme for properly handling leap seconds actually is is to look
at its data structure.  Can it represent :60 explicitly and
unambiguously?  If not, it's probably a kludge that's never going
to work perfectly.  (But, indeed, the near universality of time_t
and related representations is one of the factors that makes
"solving" the leap second problem almost impossible, and will
likely help lead to the abandonment of leap seconds.)

This message will get too long if I start discussing the data
structures that *can* represent :60 explicitly and unambiguously.
Some of them are:
* struct timespec (using the nonnormalized trick described under
  "Additional clocks" at https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html)
* struct tm
* the pair (days-since-epoch, seconds-within-day)
* a time_t *plus* a well-defined bit disambiguating the two
  instances of a repeated second across a leap second