[LEAPSECS] Time math libraries, UTC to TAI

[Steve Summit]

Brooks Harris wrote:
> It seems to me infeasible to alter the basic behavior of time_t
> because it effects every aspect of the operating system,

Absolutely.  Posix time_t is untouchable, and here to stay.

> POSIX time and 86400-second-day systems (including Windows time) will
> never exactly  match UTC at the Leap Second and we'll have to live
> with that partial inaccuracy for a long time.

Right.  (But I don't know if people will find the inevitable
discrepancies between time_t and "Time2" acceptable.)

> But a second, parallel, time system (call it POSIX Time2) could
> implement a fixed-epoch timer (call it time2_t) and a
> Leap-Second-accurate API that would yield YMDhms representation
> including 23:59:60, call them, for examples, gmtime2() and mktime2().

That's essentially what clock_gettime(CLOCK_UTC) gets you.
A struct timespec fetched with clock_gettime(CLOCK_UTC) is your
"POSIX Time2".  I have implemented gmtime_ts_r() and mktime_ts()
which operate on struct timespec, and do the right thing with :60.

> With that, those applications that needed it could use the POSIX Time2
> API, and everybody else would be none the wiser. It would also define
> the mapping between legacy POSIX and the UTC-accurate POSIX Time2.

That's exactly my intent, and I have it all working on my test
system today.  Just one or two more bugfixes and I should be
ready to post it!  (I've been saying for the past several months.)

> Eventually, maybe the file system timestamps could be augmented with
> flags to mark Leap Second instances and local time parameters.

I'm not ready to think about the filesystem yet (beyond thinking
that leapsecond-aware filesystem timestamps don't seem nearly as
important).  First I've got to get non-UTC timers (i.e., almost
all of them) working properly in the face of smeared time, and
that's going to be plenty hard, and then some.