Windows 10 and Windows Server 2019 To Support True UTC-Compliant Leap Second (thurrott.com) 67
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.
that is just great (Score:1)
Now we will have applications throwing exceptions when dealing with this (until now) invalid time,
BIOS as GMT Time (Score:3)
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? (Score:5, Interesting)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Presenting macOS, Microsoft Edition.
Re: (Score:2)
If you can't move with the times, it's time to get out of the kitchen.
Re: (Score:2)
Nah, I think we should be going back to switches on the front console. Now, that was a user interface!
http://altairclone.com/ [altairclone.com]
Re: (Score:2)
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 [wikimedia.org] has been time tested for over 3000 years!
Programming falsehoods concerning time (Score:5, Interesting)
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: (Score:2)
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 [youtu.be]
ntp vs chrystal osc (Score:2)
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: (Score:2)
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 (Score:2)
Re: (Score:1)
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 t
Re: (Score:2)
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 (Score:2)
Unix systems had it first (Score:4, Informative)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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 sys
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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 futu
Re: (Score:2)
Ahhh. Understand what you mean now. Cheers.
Re: (Score:2)
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: (Score:3)
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
Re: (Score:1)
> 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
Windows Server 2019 Features (Score:3)
Re: (Score:1)
He said Windows, so he's obviously not interested in that aspect.
Re: (Score:2)
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 (Score:3)
Known issues: Some frameworks are known to calculate time incorrectly after a leap second occurs. For example, the
Combine that with the many many steps on how to configure Win10 makes this sound like a really interesting new feature.
Re: (Score:2)
Microsoft Announces Extension of Licenses (Score:1)
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.
Go back to GMT! (Score:2)
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
New Time Protocol? PTP? (Score:2)