The Leap Second — The Second That Broke the Internet: Twice

A story about a one-second correction to the world's clocks — and what it cost the software industry every time it showed up.

Somewhere in the codebase of a major internet company, there is a comment that reads something like: "This should never be negative."

On June 30, 2012, at precisely 23:59:60 UTC, that comment was wrong.

Reddit went down. LinkedIn hiccupped. Qantas had flight scheduling problems. Dozens of systems running Linux started spinning their CPUs at 100% for no apparent reason, like a dog chasing its own tail at the speed of sound.

The culprit was not a hacker. Not a misconfigured server. Not a botched deployment.

It was one extra second, added to the world's clocks to keep them in sync with the Earth's rotation.

Welcome to the leap second — perhaps the most quietly destructive feature in the history of timekeeping.

Why Does a Leap Second Even Exist?

To understand the leap second, you need to understand that there are two completely different ways to measure time, and they do not agree with each other.

The first is atomic time. Since 1967, the international definition of a second has been based on the oscillation of cesium atoms — extraordinarily precise, completely indifferent to what the planet is doing, and accurate to within a second over millions of years.

The second is astronomical time. This is the time defined by Earth's rotation — one full spin equals one day, divide by 86,400 and you have a second. Simple, intuitive, and tied to where the Sun actually is in the sky.

Here is the problem:

the Earth does not rotate at a constant speed.

It is gradually slowing down due to tidal friction from the Moon. It speeds up and slows down due to atmospheric pressure, ocean currents, geological events, and factors that are genuinely difficult to predict. The length of a solar day drifts by milliseconds over decades.

Atomic clocks do not care. They tick forward at exactly the same rate, always. Which means that over time, atomic time and astronomical time drift apart.

In 1972, international timekeepers introduced the leap second as a patch: whenever the gap between atomic time (UTC) and solar time (UT1) grew close to 0.9 seconds, someone would announce — about six months in advance — that a single extra second would be inserted into the world's clocks. The clock would tick 23:59:58, 23:59:59, 23:59:60, then 00:00:00. A minute with 61 seconds. A day with 86,401.

Since 1972, this has happened 27 times. The last one was December 31, 2016.

All 27 have been positive leap seconds — meaning a second was added. A negative leap second, where a second is removed, has never happened. But with the Earth recently spinning slightly faster than expected, it might need to before 2035. And almost no production system has ever been tested for that scenario.

The Assumptions That Break

Most software that deals with time is built on a handful of assumptions so fundamental that developers rarely think to question them:

Time moves forward. Always. Without exception.

The difference between two timestamps is always zero or positive.

A minute has 60 seconds. A day has 86,400 seconds.

These are not just convenient assumptions. They are baked into programming languages, database engines, scheduling systems, log aggregation tools, distributed consensus algorithms, and financial transaction systems. They are the invisible foundation under a very large amount of software.

The leap second violates all of them at once.

When a leap second is inserted, UTC clocks briefly show the timestamp 23:59:60 — a timestamp that software was never designed to handle because it looks like a rollover error. Code that computes the difference between two timestamps can produce a negative number. Schedulers that fire every 60 seconds get confused. Distributed systems that rely on monotonically increasing timestamps to establish ordering lose their guarantees for one unpredictable second per insertion.

And because leap seconds are announced only six months in advance and scheduled irregularly, you cannot pre-program for them the way you can for leap years. They arrive. Systems react. Some handle it fine. Others do not.

The Incident Reports

The 2012 leap second produced one of the more spectacular mass failure events in internet history.

The Linux kernel had a bug in its high-resolution timer handling that caused processes waiting on timers to spin in tight CPU loops when the leap second was applied. The result was immediate: CPU utilization spiked to 100% across affected systems. Reddit became inaccessible for 30 to 40 minutes. Mozilla's Hadoop clusters began behaving erratically. Multiple services running on standard Linux infrastructure experienced simultaneous degradation, all at the same moment, all for the same invisible reason.

The 2016 leap second was quieter for most of the internet — but not for Cloudflare.

Cloudflare's DNS software was written in Go and used Go's time.Now() function to measure how long upstream DNS resolvers were taking to respond. The code assumed, reasonably, that the difference between two consecutive timestamps would never be negative. When the leap second caused the clock to briefly report a value slightly earlier than expected, the calculated duration came out as a negative number. This negative number was then passed to Go's random number generator, which panicked — a hard crash — because it does not accept negative input.

The result: DNS resolution failures starting at exactly midnight UTC on New Year's Day. The issue was identified at 00:34 UTC, patched on the most affected machines by 01:23 UTC, and fully resolved across the global network by 06:45 UTC. Nearly seven hours after a one-second clock correction.

The root cause, as Cloudflare's own post-mortem put it, was a single belief: that time cannot go backwards.

It's a belief most of us share. It turned out to be wrong, once, for one second, and it was enough.

How the Industry Responded (By Pretending the Second Didn't Happen)

The corporate response to the leap second problem is, in its own way, a masterpiece of pragmatic engineering.

Google pioneered a technique called leap smearing: rather than applying the extra second all at once at midnight, they spread it across a window of hours by running their NTP servers very slightly slower than real time. By the time the official leap second arrives, Google's clocks have already absorbed it gradually and don't need to make a sudden jump. From a software perspective, the second simply never happened.

Meta does the same, smearing the leap second across a 17-hour window. Amazon Web Services uses a similar approach. Microsoft adjusted Windows 10's internal timekeeping to use TAI (atomic time without leap seconds) minus a constant offset.

There is a word for this category of engineering solution:

workaround.

Not a fix. Not a principled resolution. A workaround — and one that, notably, different companies implement differently, which means that during the smearing window, clocks at Google and clocks at Meta may disagree with each other by up to 100 microseconds. For most applications, this is irrelevant. For high-frequency trading, distributed consensus, or systems that need to correlate timestamps across providers, it is not.

What a QA Engineer Should Actually Know

If your system cares about time — and more systems care about time than their developers realize — the leap second is a legitimate risk to plan for. Here is what that looks like in practice.

Test with fake time, not real time. Any system that does time arithmetic should be tested with timestamps that cross the 23:59:59 to 00:00:00 boundary, and also with the timestamp 23:59:60, which should not crash your application even if it is unexpected. Libraries and OS-level tools exist for simulating leap seconds without waiting for the real thing.

Check what your dependencies assume. The Cloudflare incident was caused by a standard library function that panicked on negative input. The question to ask is not just "does our code handle this" but "does every library we depend on handle this." Often the answer is unknown, because nobody thought to ask.

Know which time standard your system uses. UTC has leap seconds. TAI does not. GPS time does not (it is ahead of UTC by a fixed and growing offset). If your system mixes timestamps from different sources without accounting for these differences, you have a potential bug that sits quietly until a leap second arrives.

Understand smearing — and its tradeoffs. If your infrastructure provider uses leap smearing and a third-party API does not, timestamps from the two sources will briefly disagree during the smearing window. If your system does any kind of cross-source timestamp correlation, this is a real edge case worth testing.

Document your assumptions about time. "Time is monotonically increasing" is an assumption. "Timestamps from two different systems are directly comparable" is an assumption. Making these assumptions explicit — in code comments, in architecture documents, in test plans — makes them auditable. And when a leap second arrives, you know exactly where to look.

The Retirement That Isn't Quite a Solution

In November 2022, the General Conference on Weights and Measures voted to suspend the addition of new leap seconds by 2035. The decision was nearly unanimous. The US, France, and most of the tech industry pushed for it. Russia voted against it — not on principle, but because Moscow wanted more time, having built GLONASS (their GPS equivalent) to use leap-second-adjusted time, unlike GPS which does not.

After 2035, the gap between atomic time and solar time will be allowed to grow — to a value yet to be determined — for at least a century. The most likely eventual solution is a leap minute, applied once every 50 to 100 years, with the final minute of a year simply lasting two minutes rather than one. But the exact approach has not been decided. The 2026 meeting of the Conference is expected to work out the details.

The practical implication for software: no new leap seconds after 2035. Any code that needed to handle them gets a reprieve. Any tests written for leap second edge cases become increasingly academic.

But here is the honest assessment: the code that failed in 2012 and 2016 failed because of an assumption that time cannot go backwards. That assumption is also wrong for other reasons — daylight saving transitions, NTP corrections, system clock adjustments. Fixing "leap second handling" as a narrow problem does not fix the broader category of software that treats time as simpler than it actually is.

The retirement of the leap second removes one irregular, unpredictable source of clock discontinuity. It does not remove the general problem of systems that have never been tested against time behaving unexpectedly.

The Takeaway

The leap second lasted 53 years, caused incidents at some of the most sophisticated engineering organizations on the planet, and is being retired without anyone being entirely sure what replaces it at the century scale.

For a QA professional, the lesson is not really about leap seconds specifically. It is about assumptions — the kind that are so deeply embedded in how software is built that they never get written down, never get questioned, and never get tested. Until something in the physical world violates them for one second.

Time is one of the most assumption-heavy domains in software. It is also one of the least tested. The engineers who built the systems that failed in 2012 were not careless. They were making entirely reasonable assumptions about a world that turned out to be slightly more complicated than expected.

Your job is to find those assumptions before the world does.

Test thoughtfully.