- 1 What are Leap Seconds
- 2 Leap Seconds on Windows Overview
- 3 Built for compatibility
- 4 How Leap Seconds Propagate
- 5 Verify that your system got the leap second
- 6 Testing Applications
- 7 Testing Systems
- 8 Summary
Hi Everybody – Program Manager Dan Cuomo here to tell you, the IT Pro, everything you need to know about Leap Seconds on Windows. If you saw our recent blog series on the Top 10 Networking Features, you may have already noticed an announcement about Leap Second support included in Windows Server 2019 and Windows 10 October 2018 Update.
Note: If you’re an Application Developer, stay tuned for our future post Leap Seconds for the Application Developer: What you need to know
For most IT Professionals, you may not be concerned about Leap Seconds. However, if you’re a customer with time-sensitive applications or in a regulated industry requiring high accuracy time, a measly little second could hurl you into an auditing and compliance frenzy. Whether you call it a v-team or tiger-team nobody wants to have to write those status reports, After Action Reports, or Root Cause Analysis (or whatever your organization calls them) to explain just what exactly went wrong. A leap second comes and goes quickly, but the effects could last some time.
So in this article, we’ll attempt to explain everything the IT Pro needs to know so you can explain, test, and deploy Windows Server 2019 and Windows 10 October 2018 Update with confidence for your time-sensitive scenarios.
Note: Leap Seconds are only included in Windows Server 2019 and Windows 10 October 2018 Update and later releases so this content is not applicable to operating systems prior to this release.
What are Leap Seconds
Lets first understand what a leap second is. A leap second is an occasional 1-second adjustment to UTC. As the earth’s rotation slows (e.g. tidal forces, earthquakes, hurricanes, etc.) UTC diverges from mean solar time or astronomical time. Leap seconds are added to keep the difference between UTC and astronomical time to less than 0.9 seconds. Don’t worry, we don’t need to start colonizing new planets (yet ). But still, wish we found out how that jump across galaxies worked out for the Stargate Universe crew…
An organization called the International Earth Rotation and Reference Systems Service (IERS) oversees the announcement of Leap Seconds. They release several bulletins; Bulletin C is released every 6 months to confirm whether there will be a leap second or not.
Note: At the time leap seconds were introduced in 1972, a necessary correction of ten seconds was made to UTC. There have since been 27 leap seconds added to UTC for a total of 37 one-second corrections. Leap seconds are added, on average, every 1.5 yrs (NIST FAQ).
Leap Seconds on Windows Overview
Now let’s talk about some of the high-level principles needed to understand Leap Seconds on Windows.
UTC-Compliant Leap Seconds
If you are in a regulated industry, you must not only implement leap seconds, but you must do so in a UTC-compliant manner. This means that the leap second must be added to the last minute of the UTC day. During this minute, the clock goes from 0 to 60 seconds (for a total of 61 seconds).
Windows Server 2019 and Windows 10 October 2018 Update implements the leap second in a UTC-compliant manner enabling customers to meet the requirements in regulated industries.
Industry experts have gone on record to denounce leap second “smearing” – an alternative approach that carves the leap second into smaller units and inserts them throughout the day. Leap second smearing is not UTC-compliant and as such, Windows does NOT implement leap second smearing.
Built for compatibility
The majority of Windows users will not need Leap Second information; either their workloads do not depend on that high of accuracy or are not under industry regulations. If this description sounds like you, feel free to tweet a link to this blog, might I recommend…
…And feel free to stop reading. While the system (kernel) is tracking leap seconds, they will not affect your every day life as applications are never notified that a leap second is occurring unless an application has specifically “opted-in.” Applications are, by default, none the wiser unless action is taken.
This is important both for customers who have heterogeneous operating system environments to interoperate seamlessly as they always have prior to this release as well as for application compatibility. Many applications expect seconds to be between 0 and 59. If the application isn’t expecting a 60, apps could fail, cats and dogs living together, mass hysteria!
Previous Leap Seconds
For these same reasons, we do not track prior leap seconds. Our goal is to enable customers needing high accuracy time moving forward. Regulations requiring high accuracy, UTC-compliant time, did not come into affect until relatively recently, and therefore prior leap seconds are not necessary to track. For reference the last leap second prior to the release of leap-second aware Windows was December 31st 2016, that is, at the time of writing, we have not had a leap second since this date. Leap seconds after this date, will be tracked by Windows Server 2019 and Windows 10 October 2018 Update.
What happened to previous leap seconds
There’s a logical question of how previous operating systems treated leap seconds. If previous operating systems didn’t track leap seconds, are they 37 seconds off from UTC?
No, although previous operating systems did not track leap seconds, when they synchronized their time at the next interval, they recognized that they were one-second behind and time was moved forward to match the current UTC time.
A Tale of Two Timelines
“It was the best of times, it was the worst of times…It was the epoch of belief, it was the epoch of incredulity.” Since leap seconds are new in Windows 10 October 2018 Update and Windows Server 2019, prior operating systems will not know about this augmented time scale. As a result, the timelines under the hood of Windows will begin to diverge between these two operating systems as leap seconds occur.
So when the next leap second rolls in, we’ll begin an alternate timeline for Windows
Unless your application is leap second aware, it is unlikely that you will notice this delta. However if you were to view an event log from a leap-second aware system on a machine that is not aware of the leap seconds, the time displayed for the event will be off by the number of leap seconds known by the system (mmc.exe is opted-in by default).
Revert to Prior OS Behavior
As a reminder, applications must opt-in to receiving leap second notifications so leap seconds will not affect any applications by default and is likely unnecessary to modify the default behavior.
However, if you have a heterogenous time-sensitive environment you can revert to the prior operating system behavior and disable leap seconds across the board by adding the following registry key:
Value: 0 Disables the system-wide setting
Value: 1 Enables the system-wide setting
Next, restart your system.
How Leap Seconds Propagate
Every four years, we have a leap year – this is known and predictable. Leap seconds however, are different in that they are not on a regular cadence. Instead, leap seconds are announced by IERS only 6 months in advance. From there, GPS distributes the leap second notification to time servers and ultimately to Windows systems. So let’s talk about some of the mechanisms in-place to make sure that you get the leap second notification.
Time Server Distribution
The Windows Time service includes a server provider that allows a Windows system to operate as a time server. For example, when you add a domain controller to your forest this domain controller can serve time to other clients on the network through this mechanism. This is not the only method of installing a time server; you can check to see if your system is operating as a time server by using the command (Enabled: 1):
w32tm /query /configuration
The Windows Time server distributes the leap second notification to time clients. As GPS distributes time (and the leap second notification) to the Windows Time server, it will pass that notification onto clients; to be clear, your system doesn’t need to be a domain controller to do this.
But what if your system is when the notification comes? Or more likely what if you re-image your system? You’ll want to make sure that new systems know about the upcoming leap second and if the new system is created after a leap second, you’ll want to make sure that this system is synchronized with the other machines on the network.
To make sure this is possible, we’ll distribute leap second notifications through Windows Update as well. This provides a simple mechanism for reporting (nodes that have the latest updates have the leap second information as well).
Best Practice: The simplest and most effective manner for distributing and verifying leap second information across your environment is through Windows Update. If you’re on the latest updates, you’ll have the notifications!
If you have Hyper-V virtual machines, the Hyper-V virtual machine integration components will also provide leap second notifications to those virtual machines. If the virtual machine is not one of the leap-second aware operating systems (or later) this will have no affect.
Verify that your system got the leap second
In addition to verifying updates across your system, you can also use the following command to view the leap seconds known by a specific system. In the screenshot below, a positive (+) leap second will be inserted after 23:59:59 on 6/30/2019
w32tm /leapseconds /getstatus /verbose
Applications must be written to consume and process leap seconds – As you’re read a number of times already, we assume that applications are not leap-second aware. You can search every application’s documentation to find out if it’s leap second aware, or if you’re an IT Pro in one of these regulated industries, we anticipate that you will want to test and verify your application or system images for leap seconds.
If you want to manually test and opt-in an application, identify the process name, for example:
Next open the registry editor and navigate to
HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options
Add a key which is the same name as the process you want to opt-in to leap seconds. In this example, we’ve opted-in the winword.exe process by creating a Registry Key (folder icon).
Next create a REG_DWORD named GlobalFlag2 with a value of 1.
Now restart the process and insert leap seconds as before then test critical application functionality.
If your application doesn’t support leap seconds, please contact the application owner and tell them to check our future post, Leap Seconds for the Application Developer: What you need to know.
Instead of testing an individual application one-by-one, you may want to test a holistic system. To do this, open the registry editor and navigate to:
Next create a REG_DWORD named GlobalFlag2 with a value of 1 as shown here.
Restart the system then insert leap seconds as before and test critical application functionality. Note any application or system events in the event log.
Most IT Professionals may not need to be concerned about Leap Seconds. However, if you’re a customer in a regulated industries requiring high accuracy time or have time sensitive applications, you need to ensure your systems apply and maintain time accurately through a leap second. Windows Server 2019 and Windows 10 October 2018 Update brings support for, true UTC-compliant leap seconds. To make sure that these are properly implemented on your systems, you should verify your patch management strategy, application compatibility, and more.
Please give this a shot, and of course let us know how it went!
Dan “my leap seconds land on 60” Cuomo