[LEAPSECS] leap seconds in POSIX

[Steve Summit]

Warner Losh wrote:
> You've just scratched the surface of the problem.

Indeed.  (That was the third iteration of the message I sent;
the first two drafts were too long to read, due to delving into
too many details.)

> How do I touch a file on Sat, 31 Dec 2016 18:59:60 -0500 and have
> ls -l report that as its timestamp?

Sorry if this seems like a cop-out, but: you don't.  You declare
that filesystem timestamps aren't necessarily accurate to 1s
or better.  (In fact that's true today, for most filesystems,
although some have finally implemented subsecond timestamps,
and I truly don't know what to do with those.)

I had written:
>> The other basic idea is to implement new, proper-UTC-capable
>> kernel mechanisms and interfaces alongside the time_t ones.

I believe that's the best you can do today, and it ends up
involving a certain number of rather unfortunate compromises.
One is that, as I said, there are two sets of timekeeping
mechanisms and interfaces, the time_t ones and the pure-UTC ones.
Another is that these two are separate-and-unequal (on leapsecond
days, that is).  And the matrix of possibilities is sparse:

* Both possibilities necessarily exist for getting the time,
  and for converting to and from broken-down times.

* Both possibilities probably exist for interval timers.

* Both possibilities could theoretically exist for setting the
  system clock, but if it's not possible for an administrative
  utility to set the time during a leap second, if it has to wait
  for a second and set it then, I don't think anyone will complain.

* And the true-UTC alternative definitely does *not* exist
  (in my formulation, anyway) for filesystem timestamps:
  both stat(2) and utimes(2) remain time_t only.

>> Remarkably, though, *Microsoft* of all people seized the bull by
>> the horns and announced more-or-less proper leapsecond support in
>> Windows a little while back...
>
> I wonder how it deals with the externalities problems, where protocols
> specify UTC times, but then make it a simple count of seconds (ignoring
> leaps) since some epoch?

As I have written in my unpublished notes on this subject:

| If you're using absolute UTC timestamps in protocols between
| processes running on disparate systems [e.g. RTP, Chubby],
| requiring second-level (or better) synchronization, *you have a
| problem today*.  Your protocol probably breaks down at the end of
| leap second days; you probably need something like RFC 7164, too.

A kernel that is capable of faithfully delivering true-UTC
timestamps can only help the implementor of such a protocol to
get it right; I don't think it can make anything worse.

There's a subtle question about what a separate-and-unequal
kernel would deliver for time_t's on a leapsecond day.  Mostly
I think it should deliver smeared time_t's, for the benefit of
(most) programs that don't care about leap seconds, that don't
want 1s steps or other glitches, and that somehow haven't noticed
those problems yet.  But if there are programs which do care
about leap seconds, and which -- in the historical absence of
proper kernel support -- have somehow been laboriously gleaning
true UTC time from the Posix-mandated misbehavior, those programs
would be undone (until they could be rewritten to use the new,
true-UTC mechanisms, that is) by anything other than bug-compatible
Posix behavior.