[LEAPSECS] Windows Server 2019

[Martin Burnicki]

Steve Summit wrote:
> 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.

This sounds like a real step forward to flexible leap second handling by
the kernel, and IMO it would be good if this could make it into the kernel.

> 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.

I think the admins had to take care that they use a reliable clock
source. If you install a GPS receiver which outputs faulty time (e.g. to
GPS week number rollovers) or output faulty leap second warnings then
you may end up with a wrong system time. Similarly, if you chose a
smearing NTP server even though you don't want the incoming time to be
smeared.

>> 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.

However, this had to be made public so that software developers become
aware of these features and what the differences are, so they can call
clock_gettime() with the clock ID that is best suited for their
application.

If they are not aware of the differences in the clock models then their
application will probably not work as expected anyway.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy