Windows 10 and Windows Server 2019 To Support True UTC-Compliant Leap Second (thurrott.com)

Mehedi Hassan, writing for Thurrott: Microsoft is bringing support for leap seconds -- yes, that one extra second -- to Windows, starting with Windows 10 Redstone 5 and Windows Server 2019. With the upcoming updates for Windows 10, Microsoft's operating system now deals with leap seconds in a way that is incredibly accurate, UTC-compliant, and traceable. Leap seconds typically occur every 18 months, resulting in one extra second. The extra leap second occurs to adjust with the earth's slowed down rotation, and an extra second is added to UTC in order to keep it in-sync with mean solar time. To deal with the extra second more appropriately, Windows 10 will now display that extra second, instead of directly jumping to the next one. H/T Perfycat who adds: The new move makes Windows Server the first OS to have full support of the rare but valid timestamp of: 23:59:60. Linus Torvalds has long maintained that users needs to chill out about leap seconds. Further reading: Microsoft's blog post 1, and blog post 2.

Comments

that is just great

[Anonymous Coward]

Now we will have applications throwing exceptions when dealing with this (until now) invalid time,

BIOS as GMT Time

[Drakster]

Can this help with setting the BIOS as UTC time, much like all other operating systems? I know you could enable it in the past using the registry, however from what I remember, this caused further problems.

Y2K reapeat?

[kiviQr]

am I the only one that expects cities glowing in blue (BSOD) the first time system hits 23:59:60?

Re:Y2K reapeat?

[AmiMoJo]

Maybe... To get a blue screen of death the fault would have to be in the kernel, and you would hope Microsoft had at least tested that much.

Re:Y2K reapeat?

[Killall -9 Bash]

Well now that windows has joined the _____-aaS beta test clusterfuck that is modern software, I don't really expect anything.

Re:hmmm

[DontBeAMoran]

Presenting macOS, Microsoft Edition.

Programming falsehoods concerning time

[marquis111]

Puts me in mind of a very informative blog post I read years ago about popular programming falsehoods about time.

https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
https://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time

Re:Programming falsehoods concerning time

[dissy]

Another addition of fun facts on time for programmers, more specifically to time zones.
(Now with more video! Batteries still not included)

"The Problem with Time & Timezones" from Computerphile (~10 minutes)
https://youtu.be/-5wpm-gesOY

Re:hmmm

[LordWabbit2]

Or we could just go back to DOS? Would that be old enough for you?
If you can't move with the times, it's time to get out of the kitchen.

Re:hmmm

[mykepredko]

Nah, I think we should be going back to switches on the front console. Now, that was a user interface!

http://altairclone.com/

ntp vs chrystal osc

[bigtreeman]

A job I used to have was adjusting the xtal osc for "exact" frequency to keep the real time clock accurate.
Trouble is the chrystal drifts with temp and age. So how many off the shelf windoze servers have temp stabilised xtals ?
NTP is the only way to stay synchronised with the world.

Re:ntp vs chrystal osc

[guruevi]

You could use GPS or atomic clocks for your computer. A bit more expensive than the crystal but if you need it...

Re:ntp vs chrystal osc

[Anonymous Coward]

You're right--but what they're doing is improving NTP by allowing the NTP driver better information about when a packet arrived (stamping the packet in kernel mode) -- or true leap second support. They're also allowing NTP to tweak the system clock by 100 nanoseconds per second instead of the old (coarse) limit of 6.4 microseconds per second (6400 nanoseconds per second).

Basically... they're allowing NTP to get the system clock more accurate than before and to help document that NTP is keeping your clock that accurate.

They're also supporting PTP (Precision Time Protocol) which is more accurate than NTP as it measures and compensates for packet latency in switches (!).

Re:ntp vs chrystal osc

[Interfacer]

You do realize the clock is implemented in hardware and unrelated to whatever OS happens to be installed? But yeah. 'Boo Windoze'

Re: ntp vs chrystal osc

[coolsnowmen]

Fun fact: crystals typically increase in frequency over time because the mechanical wear causes them to lose mass

Re: ntp vs chrystal osc

[coolsnowmen]

I believe it is a common abbreviation in Circuit design.

Re:hmmm

[dissy]

Nah, I think we should be going back to switches on the front console. Now, that was a user interface!

Pft, you kids and your switches and lights and visage ledgers.

This UI has been time tested for over 3000 years!

Unix systems had it first

[guruevi]

Leap second support has been in Linux and other Unix systems forever. The problem is the many standards on how to implement leap seconds. They are generally a representational problem, not a counting problem. It’s similar to time zones, they are arbitrarily defined and thus not very useful for true mathematical implementation. Microsoft has picked one of the dozen or so standards on how to represent leap seconds. The fact is that you should pick whatever method is suitable and useful for interoperation with the rest of stuff you have.

Re:Unix systems had it first

[thegarbz]

Leap second support has been in Linux and other Unix systems forever.

This isn't an article about who coped with leap seconds first. Windows has done this for a long time too. This is an article saying that Windows is the first system to give a UTC complaint solution to the problem. Linux / Unix don't currently ever return 23:59:60 as a valid time for any normal time related system call.

Re:Unix systems had it first

[guruevi]

System calls should not return a representation of time, they should return a valid time stamp that can then be interpreted by the UI layer according to user settings.

Re:Unix systems had it first

[thegarbz]

Which comes back to my point: Unix's seconds since epoch does not account for leapseconds and thus isn't UTC compliant.

Though I disagree somewhat. Leaving it up to the UI layer results in different representations of time to the user for different applications. I get it time is hard to deal with but it should be hard for programmers, not hard for users.

Re:Unix systems had it first

[tlhIngan]

I get it time is hard to deal with but it should be hard for programmers, not hard for users.

No, it shouldn't be hard for programmers either. After all, it's why we have things like libraries. All the complexity of date and time handling should be contained inside a well-known library so everyone knows to use those functions instead of trying to "wing it" with their own date and time "library".

The date/time library is what should be handling all the tricky stuff.

Re:Unix systems had it first

[thegarbz]

After all, it's why we have things like libraries

I know. Libraries are just delivered by magic unicorns. /sarcasm. My point was not application programmers, but rather programmers in general. Time is hard. Even when you think you can offload it to a library time is still hard. Even if we have a perfect time keeping library you still end up dealing with application requirements that will require time to be handled in a special way, e.g. a calendar or an app that communicates between different countries.

Programmers need to remain vigilant even when they do use libraries. Time is hard.

Re:Unix systems had it first

[thegarbz]

1) Seconds past the epoch DOES account for leap seconds, those seconds are just seconds, and are counted.

Maybe you should actually read how seconds past epoch work in the Unix world before you comment, because they are expressly not counted. Worse still the way they are not counted varies by implementation in the Linux / Unix world. e.g. RedHat with the NTP client setup as defaults will cause the system to roll back the clock by 1 second and repeat 23:59:59 twice. Other systems will repeat 00:00:00 twice. This causes many problems for applications. You can also configure Linux to slew the timer causing the system to run slower or faster, bringing it out of sync with others. This breaks time sensitive applications. Or you can configure to ignore it which causes loss of synchronisation and really at that point why even bother trying to represent time in UTC anyway.

2) The OS layer should be CONSISTENT, and SPE is.

As said above SPE is not. The only way the OS layer can be consistent is to recognise 23:59:60 as a valid time or to give up the idea of being UTC, represent time as TAI (something that you're claiming incorrectly that SPE is doing by counting leap seconds) and let the application layer figure out what the heck the time actually is depending on the user requirements.

Re:Unix systems had it first

[guruevi]

UTC is a time representation, to be accurate and useful in programming, a clock cannot do the representation part.

Leap seconds are arbitrarily defined like time zones, clocks in low-level system calls should not care about them.

Leap second may be inserted at the end of some other hour (or half-hour or quarter-hour), depending on the local time zone

Re:Unix systems had it first

[thegarbz]

UTC is a time representation, to be accurate and useful in programming, a clock cannot do the representation part.

I don't follow.

Leap seconds are arbitrarily defined like time zones, clocks in low-level system calls should not care about them.

Indeed they shouldn't care about them, but they should accommodate them. If you don't accommodate them you end up with a various sets of ways of compensating for them each with different drawbacks.

Leap second may be inserted at the end of some other hour (or half-hour or quarter-hour), depending on the local time zone

Having a system that is flexible enough to pick where to insert that leap second is the trivial part of solving this conundrum.

Re:Unix systems had it first

[gdm]

> Unix don't currently ever return 23:59:60 as a valid time for any normal time related system call

I'm not sure I'd agree with that. If you look at the contents of struct tm, as returned by various time-related calls, you'll see:

                      int tm_sec; /* Seconds (0-60) */

That's 60, and not 59, for a reason. If leap seconds are added at midnight in your time zone, then you could see the 60.

g

Re:Unix systems had it first

[guruevi]

but they should accommodate them - And that is where you don't understand the difference between a clock and a time representation.
A clock keeps track of time, eg. how many 'ticks' since a certain epoch (eg. since the computer started or a job ended or since 1970/01/01 or every time a crystal under pressure emits a signal). So in programming you typically keep track of time this way, you count the number of ticks (eg. every millisecond or every second) has elapsed. You want to schedule something in the future, you add n ticks and wait for that number to equal the number in the register.

Time representation is when you tell the user "what time is it". Eg. you define United_States/New_York to be "your time zone" so it will do some library call to get the number of 'ticks' (the clock running in TIA/GPS) and then a translation for whatever your local politicians defined your time zone to be today. As of 2012 you also have to adjust for the difference between TIA and UTC. Leap seconds and leap days/years etc are part of the representation and depend on not only what you want to do but also what your user prefers or needs to use it for. In some cases, China may decide not to insert a leap second (they've already indicated they want to get rid of that system) and then your library call is either useless or wrong (and in most cases it will end up being wrong).

In this case, Microsoft wants to build into the low level library that when you call for the 'clock' it will return the arbitrary UTC time representation. Windows historically has not done true clock representation, they always set your system clock to your localized GMT+n time even though it's supposed to run in TIA or GPS (or at worst UTC/GMT+0). It's a complicated thing to implement calendaring and timing, but doing it in a low-level library is wrong because those calls are supposed to be stable and predictable. In this instance, you cannot use this library call for example to schedule things 6 months in the future, since you don't know what UTC will be 6 months in the future since it hasn't been decided yet whether a leap second will be inserted. Every 6 months the committee that decides when to insert leap seconds decides when to insert leap seconds next, that causes issues if you want to run a timer based on UTC for more than the delta between your current time and the insertion of the leap second.

Re:Unix systems had it first

[thegarbz]

Ahhh. Understand what you mean now. Cheers.

Windows Server 2019 Features

[DickBreath]

The only feature I need in Windows Server 2019 is to be able to set my hostname to all emoji characters. Thank you.

Re:Windows Server 2019 Features

[aybiss]

He said Windows, so he's obviously not interested in that aspect.

Re:Windows Server 2019 Features

[DickBreath]

If other network users on the LAN can see my workstation as all emoji characters, then what else needs to actually work?

It doesn't HAVE to work. There are millions of people who run Windows every day and aren't aware enough to be ashamed or embarrassed.

read the MS Dev document

[at10u8]

The MS blog entry points at a Dev document about how it works, and that says this:
Known issues: Some frameworks are known to calculate time incorrectly after a leap second occurs. For example, the .NET Framework uses its own internal logic to determine what time it is. Its logic does not account for leap seconds. So after a leap second is introduced to the Operating System the output of "System.DateTime.Now.ToString()" will be ahead by one second of the local system time. (We are working with the .NET framework team on this.)
Combine that with the many many steps on how to configure Win10 makes this sound like a really interesting new feature.

Re:read the MS Dev document

[complete loony]

Changing the OS to track leap seconds is one thing. I want to know how the time value returned by the various OS and application framework API's will change. Getting that right is important, but also much more difficult.

Go back to GMT!

[31eq]

After thinking about this far too much, I've concluded that POSIX should go to some form of GMT that isn't UTC, either UT1 or UT2, whatever the difference is. It keeps the numeric timestamp meaningful: you can get the time and date most of us care about with basic arithmetic and no lookup tables. Future timestamps will work the same way. Unless you really need to know the current time in UTC, in which case you'll need a lookup table, which is simple enough as predictions are published that should be good enough. Software that cares about UTC can use lookup tables to give you the real time corresponding to your GMT timestamp, which means full leap second support for software that cares without burdening the hardware clock or software that doesn't care. And your historical timestamp might even record a leap second you didn't know about because your time zones files were out of date when you recorded it. No abrupt changes as we pretend UTC and GMT are really the same. No historical times that can't be represented.

If you really care about UTC, you can always set your clock to atomic time and use the "right" timezones the same way nobody does now and leave the rest of us alone.

Networking protocols can be designed to work if two devices pick different standards and end up being (shock!) up to a second different.

(I don't know how Microsoft are implementing the headline changes. I read the article and the article it links to, and they still gloss over the details.)

Who's with me?

New Time Protocol? PTP?

[jsrjsr]

The article refers to a new time protocol known as Precision Time Protocol (aka PTP). This protocol has been around for a while -- v1 came out in 2002, v2 in 2008. It's implemented mostly in industrial control networks like EtherNet/IP.