[LEAPSECS] Time math libraries, UTC to TAI

[Steve Summit]

Brooks Harris wrote:
> We're stuck with a giant legacy of 86400-second-day based systems, from 
> the operating systems to applications that rely on them, from SQL to 
> banking systems, from Excel to email. These systems must continue to 
> operate as expected, even if they're all inaccurate with respect to UTC 
> and/or ambiguous with respect to local time representations.
>[...]
> The existing systems are not going to be replaced; they all need to be 
> supported while defining a more uniform and UTC-accurate set of 
> procedures that may be used in parallel with, beside, on top of, or in 
> conjunction with, existing systems. If we keep arguing about what UTC 
> and POSIX are or are not because we don't like one or the other I don't 
> see how we get very far.

It seems to me we're stuck between the rock of Posix time_t that
simply doesn't handle leap seconds, and the hard place of UTC
that still has them.

And it seems to me it's an untenable situation.  (I'm
summarizing; I'm sure readers of this list understand all this
at least as well as I do.)  We've got all sorts of wonderful
mechanisms (NTP et al.) that keep all our computers synchronized
to within milliseconds of each other, but then every 18 months or
so some minuscule version of hell breaks loose, when practically
every computer on earth ends up jumping a whole second, or
repeating a whole second, because there's just no place in the
time scale for the leap second.  It's a mess; it's just about
like jamming a 13th egg into a one-dozen carton.

It seems to me we have two choices: handle leap seconds
considerably better, or abandon them altogether.

If we try to handle them better, two conclusions seem inescapable:

1. Posix-compatible time_t values will need to be smeared,
   spreading the leap second out more gradually, to eliminate
   sudden, unseemly jumps.

2. There needs to be a well-defined way to deliver true,
   non-smeared, leapsecond-aware UTC time to code that needs it.

Putting these together, I conclude that any smearing for #1 needs
to be done in the OS kernel, just before delivering leapsecond-
unaware Posix-compatible time_t values.  Doing the smearing anywhere
upstream (as, for example, Google is doing it) precludes #2.

As a proof of concept, I'm working on a set of Linux kernel mods
to do both #1 and #2.  I had hoped to have them ready for
interested people to experiment with this Saturday, but
unfortunately I'm not going to make it.