Categories
Uncategorized

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., 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]

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

lol!  People are freaking out about a leap second?  How often do people even keep their computers synchronized to the correct minute, much less the correct second?

M3 Sweatt

The link you provided (in your comment above) doesn't seem to be valid

Apologies. Corrected to the TechNet article on "What Is Kerberos Authentication?" #tinykeyboardissue

Can windows servers automatically manage leap second issue or human interfere required?

Having read your various posts about this I think you're missing the bigger picture.  The Internet doesn't run from a collection of individual people's workstations it runs from a collection of servers.  Our perception of the Internet is based upon the relative health of those servers.

Imagine a server which needs to process things or route packets or which involves cryptography to include two-factor authentication hardware.  Accurate time is of the essence.  A recent trend in the industry has been to re-tool everything as asynchronous, meaning that synchronous programming is now to be avoided.  A *synchronous* program thread will just run until it's finished and everything else will just wait of it.  *Asynchronous* programming implies that the system identifies something that would take a long time and to spin that off as a separate thread.  The system is then responsible for triggering these extra threads to run and the programmer is given control of that; the number of milliseconds to delay are part of the program.

A Google search for the term node.js turns up about 19M hits.  Node.js is part of the bigger "open source" picture and is hugely popular now.  You wouldn't believe the number of companies and systems that are built using this platform.  Think of it as layers of free code built on top of free code on top of free code…

Underlying all this is the concept of time.  Time in these systems is defined as the number of milliseconds since 1/1/1970.

Back to Node.js, any project built using this system has an entire tree of dependencies.  One of those dependencies is ms, a module which returns the number of milliseconds.  Your Node project might include four different versions of ms within its tree.  Even if the author of ms discovered and patched a leap second–related bug in his code it would take a huge amount of effort to propagate that fix out to the countless other modules which use it and then to the countless projects that use them.  Looking at the repository for ms I see that it was downloaded eight million times (to be included into projects) last month alone.

What will happen to code which is scheduled down to the tenth of a second when time changes so greatly?

Someone could easily suggest that the collection of servers on the Internet is a house of cards waiting for the next breeze.  I don't think it will fall tonight but you may easily expect a higher level of problems than were seen back at the last leap second event.

I appreciate your perspective and understand your comment WRT the bigger picture. And you're right that the relative health of the servers and systems that make up the cloud is important.

As my focus is on Microsoft infrastructure, my comments are primarily on products like the Windows OS. I understand the concerns of the other technologies and systems (such as your example of node.js) and the challenge that a time-related bug in one piece of code could cause an issue to other connected systems. I'm not sure that this means that there is a higher propensity for an issue today vs. when the last leap second was added in 2012.

I do concur that there certainly could be issues for unpatched servers or new code which has a related time-based bug, particularly for time in high-accuracy environments (such as your point on code scheduled down to the tenth of a second).

Comments are closed.