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

Re:Whoohoo!

[Anonymous Coward]

Still supported UTF-8 decades before Slashdot.

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.

Re:Whoohoo!

[Anonymous Coward]

awww cant communicate wifout pikchas still? awwww.

hmmm

[kjhambrick]

woop-de-freakin-do

Is that kinda like setting your watch while sitting on the couch while your house is burning down ?

When are they going to replace that abomination of a user interface with something more usable ?

Say maybe like Win7 or anything older than that ?

-- kjh

Re:hmmm

[DontBeAMoran]

Presenting macOS, Microsoft Edition.

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/

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!

Re:hmmm

[Anonymous Coward]

I was a huge fan of xp. Things have bounced around a bit since then (vista... down, win7... up, win8... fell so hard it damaged the foundations) but the trend is a steady downhill.

Re:Whoohoo!

[Anonymous Coward]

Awww can't support basic technologies that even toy websites can? Awwww

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.

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:Programming falsehoods concerning time

[Anonymous Coward]

Same presenter has a great video on Internationalis(z)ing too

https://www.youtube.com/watch?v=0j74jcxSunY

Re:Programming falsehoods concerning time

[Anonymous Coward]

Programmers code to the self learned and used constructs. PERIOD. time is 12:00 AM/PM format. That is not a standard is just is.

Is Midnight the first or last monument of a day? Fact it is nether. Just liek 12noon is not AM or PM. These are false continued today with ALL Microsoft software.

What is processing speed induced errors: IBM equipment when reading time quickly across midnight you got:
23:59:59 1988-01-01
00:00:00 1988-01-01 -- 24 hrs backwards.
00:00:00 1988-01-02
00:00:01 1988-01-02

And that was hardware for the time and software for the date. But reads as a single "thing' Had to add code to watch for and ignore this error... blew a few interfaces up first, though.

Also there is no define other than a astrological time keeper, that made midnight the first instance. They just choose that, becuase it was easy. Also for those clock, guess when the data changed? 12noon Else it cause hickups during telescope tracking for stars. Again that was the 80's.

HAd to corrrections

Re: Programming falsehoods concerning time

[Anonymous Coward]

time is 12:00 AM/PM format

Actually, the US is almost unique in doing that, the rest of the world uses 24 hour time

Re: Programming falsehoods concerning time

[Anonymous Coward]

Yes and we don't have to ask ourselves "oh shit is midnight 12AM or 12PM?"

Re:Programming falsehoods concerning time

[Anonymous Coward]

My guess is torn reads due to non-atomic updates to the data structure holding the time.

Really Microsoft?

[Anonymous Coward]

All the shit wrong with Windows 10 and this is where you've been spending your development time? *facepalm*

Re:Really Microsoft?

[Anonymous Coward]

Development time will not matter, they have had years to progress the operating system model and have chosen to regress it in terms of utility to the end user while enhancing utility to 3rd parties who remotely access the machine.

I think the fact that you are posting about windows indicates you still use it, there is a judgement in that, you know perfectly well that this is indeed finally the year of Linux and the time to switch is rather obviously now as everyone is beginning the mass migration now that the frontier of Linux has been scouted and found to be hospitable to getting things done.

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

[Anonymous Coward]

GPS is no good, but CSACs (chip-scale atomic clocks) do exist, are under US$ 1k, and could indeed be used. But they draw a lot more power than an uncompensated xtal :(

Re:ntp vs chrystal osc

[Anonymous Coward]

Back when I ran a mixed shop. The windows (XP) machines finally had a built-in ntp client! They ended up claiming stratum 3 (my Unix ntp servers ran at 2), and managing to be three minutes(!) off, easily. While offering their Micorsoft Quality Time Information for all the world, of course. Default settings of checking the time once a week, and the only way to beat that into submission was registry settings, of course. Thanks, microsoft.

Did they at least fix that bit of microsoft standard issue utter degenerate idiocy in the meantime?

Re:ntp vs chrystal osc

[Anonymous Coward]

Not really. The only reason that Windows needs timesync is for authentication, and that only needs synchronization within 5 minutes or so (the anti-replay is very course).

Current versions of Windows almost do NTP, almost but not quite.

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

[Anonymous Coward]

Why are you to lazy to type crystal?

Re: ntp vs chrystal osc

[Anonymous Coward]

Why are you too lazy to type too?

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.

First and second

[Anonymous Coward]

Leap might be second but the first goes to Ubuntu and it's derivatives like Linux Mint. :)

 

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

[Anonymous Coward]

I disagree:
1) Seconds past the epoch DOES account for leap seconds, those seconds are just seconds, and are counted.
2) The OS layer should be CONSISTENT, and SPE is.
3) The UI can interpret the SPE count in whatever way it thinks appropriate, as long as it is consistent with itself, and stores final answers in SPE, the system will be consistent.
4) The UI can also be made to be consistent, but separate from the SPE implementation.

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

[Anonymous Coward]

There's no way to avoid the complication. At best you can move it around.

There's no way you, as a programmer, can avoid knowing about leap seconds. If you are going to be dealing with times coming from an external source (like a file or a user), you have to know that you may see a time like "12:59:60". You can restrict user input to not accept leap seconds, but then you will be unable to parse times generated by the system during leap seconds. You can tell the library whether to allow leap seconds based on whether the input comes from a user or the system, but then you still have to know about leap seconds!

dom

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

[Anonymous Coward]

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

you forgot to ask for an actual working operating system

Re:Windows Server 2019 Features

[aybiss]

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

Re:Windows Server 2019 Features

[Anonymous Coward]

Mine is Pepe the Frog, Eggplant.

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.

Re:Whoohoo!

[Anonymous Coward]

Fake News: The link pointing to https://www.wired.com/2015/01/torvalds-leapsecond/
is a FAKE ARTICLE. It's obvious 'cause there isn't a single swear word in the whole of the text.

CAP === 'sweetens'

Microsoft Announces Extension of Licenses

[Tokolosh]

Microsoft today announced that existing licenses and support agreements will be extended at no additional cost.

Government spokesmen welcomed this generous gesture and hailed the effectiveness of the President's negotiating skills with the Seattle company.

Re:Whoohoo!

[Anonymous Coward]

Awwwww can't get everything your way for free? Awwwwww

outright stupid

[Anonymous Coward]

No Software out there supports that. So why the would an os expose Software to that kind of crap? Simply ignore leap seconds, step, or slew them over the last minute.

cascade

[Anonymous Coward]

It will surely be fun to watch how this new "feature" cascades down into all the dependent/forgotten pieces of windows infrastructure :D
Just imagine all the resulting hilarious bugs popping up across all the unprepared subsystems :D

Re:Whoohoo!

[Anonymous Coward]

And yet Outlook still lets you book a meeting during the DST leap hour that doesn't even exist i.e. 02:30.

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.