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., time.windows.com) sync with authoritative, atomic clock time servers such as those maintained by the National Institute of Standards and Technology (a.k.a. NIST, at bldrdoc.gov). 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, time.windows.com. 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 time.windows.com will eventually sync to the current, accurate time reflecting the leap second. As time.windows.com 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 http://bit.ly/leapsecinfo
[edit: added information in ¶2 on domain-joined devices; added detail in ¶3 on the binary nature of the leap second via NIST]
