The story around Leap Seconds and Windows: It’s likely not Y2K

Today I woke to a number of hair-on-fire press articles decrying the coming and dreaded Leap Second… with the mainstream USA Today calling out…

“But last time it happened, in 2012, it took down much of the Internet. Reddit, Foursquare, Yelp and LinkedIn all reported problems, and so did the Linux operating system and programs using Java.”

Not quite correct: IIRC, although some may’ve succumbed to bugs noted in Wired, several popular Internet services (including some of those mentioned) went off line due to a serendipitous and unfortunately timed power outage that impacted their service provider as chronicled by the BBC.

So, why isn’t Windows mentioned?

Glad you asked.

As I noted a couple of years ago, you’ll find more documenting the impact of a leap second in heartwarming Knowledge Base article “How the Windows Time service treats a leap second” and (excerpted) for everyman by the well-read and  Michael Kaplan. Essentially, after the leap second occurs, the NTP client that is running Windows Time service is one second faster than the actual time. This time difference is resolved at the next time synchronization.

“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.

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.

As The Telegraph noted, “Many computing systems use the Network Time Protocol, or NTP, to keep themselves in sync with the world’s atomic clocks.” As called out on the Windows site with instructions on How to Set the Clock, you can sync your device clock with an Internet time server of your choice to help ensure your device’s clock is accurate. Typically time is updated once a week (when connected to the Internet – who isn’t?), or the clock sync may be managed by your administrator (with domain joined devices). As a user, you probably won’t notice the extra second nor see any impact to your Windows devices.

In addition to the historical blog record in the Windows Time Service blog, more articles/ information in which you may be interested:

Generally, consumers have nothing to worry about when it comes to this non Y2K event. IIRC, the concept of a leap second is actually in question, and an ITU working group has debated whether or not adding/subtracting leap seconds should be discontinued (as noted here). We’ll see what 2015 brings. Or January, 2038 for that matter.

BTW, a few additional notes today from my associate and venerable time lord Matt Johnson

“It may be worth noting a couple of things from a developer’s perspective:

  • Most applications do not handle leap seconds, as their time structures only allow seconds numbered to 59 – not to 60.
  • Most applications do not care about this, as they will never receive a leap second from the system clock – even when one occurs.
  • Most applications have to cope with minute time adjustments to the system clock for a variety of other reasons anyway – so leap seconds are no different.  Consider that clock drift does occur, and is often corrected by NTP sync – so it’s not abnormal for an app to receive timestamps out of sequence.
  • Depending on implementation, sometimes a system just won’t observe the leap second at all, but that just means its clock will be off by one second until the next NTP sync.
  • Even when the leap second is observed perfectly, it only affects code that needs to be precise to sub-second accuracy.  Consider how the clock will tick over an observed leap second when you observer it by tenths of a second: 23:59:59.8, 23:59:59.9, 00:00:00.0, 00:00:00.1

“So, it usually doesn’t cause a problem unless you are timing things less than a second in duration, or if you are re-sorting events that occur in high frequency.”

[Note: Part two of the story around Leap Seconds and Windows: #NotY2K]

Also available at

2 replies on “The story around Leap Seconds and Windows: It’s likely not Y2K”

'Leap seconds' are just time tics that have been happening for decades.  It's only noticed at the consumer level with so much reliance on GPS.  In fact in the 1980s there were such corrections almost every 6 months.  To decline to once in 3 years is a testimony to how well modern time standards are operating for the benefit of downstream systems like NTP.  That some applications may have a problem is just a reflection of passive negligence; same being true for Y2K round 2 coming with Dec 31, 2028.  You can be sure there will be public panic about it and USA Today like 'tech' sources will worry the world over it.

Quite right and accurate WRT GPS.

And on "Y2K round 2" coming Dec 31, 2028, I know there's a total lunar eclipse expected then, but not aware of a date / time issue in 2028. There is a known NTP issue in 2036, and the year 2038 problem for older devices that calculate or store time and date as a 32-bit integer.

Comments are closed.