[LEAPSECS] Windows Server 2019

[Steve Summit]

Steve Allen wrote:
>> as seen on slashdot and more, Windows Server 2019 will support
>> leap seconds.

I don't often say this, but: Good for Microsoft.

Despite the several, well known, significant difficulties, I have
been on a quixotic on-and-off quest to implement "proper" leap
second handling for Linux.  (As some will recall, on 2016-12-31
I managed to post a message to this list at 23:59:60 UTC, with a
Date: line to prove it.)  If anyone feels shamed into action by
Microsoft's announcement, and wants to try things out under Linux,
please feel free to pester me into finally publishing that work
publicly. :-)

Stephen Colebourne wrote:
> ...it needs to be possible for any of these setups to be valid
> (and maybe more options too):
>
> - network clock returns UTC, OS handles UTC, application/framework handles UTC
> - network clock returns UTC, OS handles UTC, application/framework smears
> - network clock returns UTC, OS smears, application/framework unaware

The modified Linux kernel that I have implements these sorts of
choices via clock_gettime().  The new clkid value CLOCK_UTC gives
you true UTC, the new clkid value CLOCK_SMEARED gives you smeared
time, and the existing clkid value CLOCK_REALTIME currently gives
you whatever we used to put up with (basically a repeated second),
but could/would be changed to return the same as CLOCK_SMEARED
once it was confidently proved to be working.

The question of what happens if you try to run a leapsec-aware
kernel downstream of a smearing NTP server is an interesting one.
My preferred answer is "Don't do that."  The failure modes if you
did wouldn't be *too* bad, but "proper" handling of CLOCK_UTC in
that case would of course require an unsmearing algorithm, which
I for one am not interested in writing.

> Getting the smear off the network and into the OS will undoubtably
> be useful in some use cases, but they are not the only use cases.

Indeed.