Another look at the impact of the coming 2015 leap second on Microsoft products (not much)

Drawing of a man holding back the hands of a clock with the caption "You can't stop time"A month from now, we should be looking back at the press that decried the coming Leap Second (caps my own) as a veritable Y2K and wondering “what was all that about?” As I’ve shared previously (see “What’s all this about the Leap Second”) I’ve learned quite a bit about how Microsoft products and services address the addition of a new leap second. Most often, issues of time and date are addressed by the groups involved in managing the Windows OS, plus in this instance by the team managing the Windows Time service. Many of our products and services rely on the underlying OS for time and date, much like the support for daylight saving time and time zone support. There’s a great TechNet post that covers How the Windows Time Service Works.

What you likely need to know: On the Windows Client, current supported versions of Windows are plumbed to deal with such leap second changes via an NTP ping in the Windows Time service (a.k.a. W32Time), as I summarized here. As you may know, W32Time handles regular clock sync, and as root time sources are updated, changes propagate through NTP and adjust network synched clocks. I outlined much about what you may want to know in my post on the story around Leap Seconds and Windows. Essentially, set your PC to sync with an Internet time server via the Control Panel in Windows 7 (as noted here), or in the PC Settings for “Time and Language” in the Control Panel on Windows 8.1 (as shown here), and you’re good to go. (If you’re device is part of a domain – such as PC provided by your company for business – then your clock sync is likely managed by your IT administrator, so again, you should be good to go.)

Background on how a leap second is added: When a leap second is to be added, a notification is broadcast on the day of the event (sometimes in the hour prior) via an NTP flag from the NTP server to all NTP clients. Time services (e.g., sync with authoritative, atomic clock time servers such as those maintained by the National Institute of Standards and Technology (a.k.a. NIST, at These facilitate regular clock sync, and as the root time sources are updated, changes propagate through NTP and adjust network synched clocks as well. Technically, IIRC, the leap second is applied by NIST on NTP as a second iteration (a repeat, actually, in binary) of the final second of the day, and would look something like this: “23:59:58… 23:59:59… 23:59:59… 00:00:00UTC”. (BTW, some systems interpret this last second as 23:59:60.) Think an abbreviated, one second version of the issue Emily Blunt faced in Edge of Tomorrow, but without all the bloodthirsty aliens and general mayhem.

How a leap second is reflected in Windows: Contrary to one post I recently read, Microsoft doesn’t implement a leap second time zone by time zone – in other words, in a rolling fashion, like the way we watch new year celebrations count down around the world. Essentially, the leap second occurs at the same time everywhere. Just when your individual device syncs with NTP will likely be different from others. Windows devices that are joined to a domain will attempt to sync with the domain hierarchy. Consumer devices that are not domain joined, sync time less frequently or have intermittent network connections sync the clock most commonly to the Microsoft NTP server, As these systems do not sync the clock frequently, we’ve stated that “it is impossible to guarantee time accuracy on computers that have intermittent or no network connections.”

Devices that are synched with will eventually sync to the current, accurate time reflecting the leap second. As syncs with NIST time servers, Windows devices are generally accurate and in sync subsequent to the addition of the leap second. Many devices will sync within the first few seconds of 00:00:00 UTC (which some may refer to as “midnight UTC”) on June 30, 2015 / July 1, 2015 as they ping the service. But of course, not all systems sync at or close to 00:00:00 UTC. Microsoft has outlined that W32Time service is not a full-featured NTP solution that meets time-sensitive application needs (see Microsoft KB 939322, Support boundary to configure the Windows Time service for high-accuracy environments). Companies that require critical timing systems usually implement a specific reference clocks that provide highly accurate hardware clock, which when used with Windows, use their own incredibly accurate clock drivers. Whereas Windows is supported to be accurate within something like 3 seconds, these clocks are accurate to within <1s. (If you want to get all nerdy, my friend, Matt, reminded me of my desire for a Meinberg clock, and a great summer project you can DIY with your kids.)

How the leap second is reflected in services:  Various cloud systems obtain NTP sync in much the same way. How leap seconds are applied to and appears on a local machine clock may be different, but this is well documented and understood in Windows, upon which Azure has its origins. (More on that in a second – see also the info in Microsoft KB 909614, How the Windows Time service treats a leap second, and KB 939322, Configuring the Windows Time service for high-accuracy environments.)

In speaking with the Azure team, I learned the service has been designed to be resilient to clock discrepancies across our numerous infrastructure components and regions. Azure has proven application compatibility for handling leap seconds given it uses the Windows time-synchronization protocol, which is used by all Windows systems including the Windows client OS, Windows Server, Windows Phone, and Hyper-V. When the last leap second adjustment was made (back on June 30, 2012) we had no reports of leap second issues for any of our products across Windows, Azure, or the customer applications running on Azure. Similarly, I understand that other Microsoft services, including as Office 365, Dynamics CRM Online, Intune and Azure RemoteApp services, aren’t affected by a  leap second change. I’ll add additional information here as I come across it.

Generally, Microsoft products (e.g., Exchange, Office) and most/all third party apps rely upon W32Time to provide an authoritative view of time, using UTC rather than local time (the time you see displayed by your Clock app and in the Date & Time display). As long as the OS is able to manage the leap second change, dependent applications should generally be fine: there could be implications for apps or services that do not follow standard clock implementations. If an app or service uses another time sync method or has other time dependencies then there could be an impact (e.g., presenting an app with a time reference of 23:59:60 when it doesn’t expect to see seconds greater than :59). More info on some of these concepts with appropriate links here.

Article also available at

[edit: added information in ¶2 on domain-joined devices; added detail in ¶3 on the binary nature of the leap second via NIST]


Your questions: What’s all this about the Leap Second, and how does it affect the Microsoft Windows OS and other products?

First off, Happy Canada Day. (eh? 😉

Lots of talk today about the ‘Leap second bug’ that caused various site and software crashes (see this post via CNET)…

“The addition of a leap second to the Coordinated Universal Time at midnight Greenwich Mean Time last night appears to have caused site disruptions for a handful of popular Web sites and software platforms.

“The adjustment, which was made by International Earth Rotation and Reference Systems Service, was necessary to keep atomic clocks in line with the Earth’s ever-changing speed of rotation. Dozens of leap seconds have been added since their introduction in 1972.”

Once again, The Extra Second was too much for some sites. Sounds like a new James Patterson crime novel. Or perhaps a new thriller from our own Mark Russinovich… I prefer his writing more these days anyway.

As I noted a couple of years ago, you’ll find more documenting the impact of a leap second in Microsoft Knowledge Base (KB) article 909614, How the Windows Time service treats a leap second (as Michael Kaplan noted in his most excellent post)… 

“In short, W32Time does not account for a leap second being dependent on the NTP server. Most applications and services may be unaffected, but sysadmins and IT professionals should know that the leap second is not addressed until the next time sync following the official addition/ subtraction of the leap second.  Consumers really have nothing to worry about save questioning whether or not the time is accurate as broadcast during Dick Clark’s New Year’s Rockin’ Eve when the crystal ball drops in Times Square.

“Info on syncing clocks to absolute time, please see KB 816042, How to configure an authoritative time server in Windows Server 2003, and KB 884776, How to configure the Windows Time service against a large time offset.

“General information on the Windows Time Service is also available in the team blog at  More articles/ information in which you may be interested:

IIRC, the concept of a leap second is actually in question, and an ITU working group is evaluating whether or not the process of adding/subtracting leap seconds should be discontinued.


Tags: Microsoft, Daylight Saving Time, Daylight Savings Time, leap second, DST.

Bookmark and Share

Also available via