What Are Leap Seconds and Why Do They Cause Software Bugs?

A leap second is a one-second adjustment inserted into Coordinated Universal Time (UTC) to keep our clocks aligned with the Earth’s actual rotation. It sounds harmless. In practice, it has crashed major internet services, broken financial systems, and triggered hours-long outages — to the point where the international metrology community has voted to abolish it.

Why a leap second exists at all

UTC is built on atomic time. Atomic clocks tick with extraordinary regularity — one second is defined as exactly 9,192,631,770 oscillations of a cesium-133 atom under specified conditions. The Earth, however, is not so regular. Tides, atmospheric mass shifts, ocean currents, and the redistribution of mass after large earthquakes all change Earth’s moment of inertia. The day gets a few milliseconds longer or shorter than 86,400 atomic seconds.

Over years, those milliseconds accumulate. By the early 1970s, the difference between atomic time and astronomical time was approaching a full second. Without correction, our clocks would slowly drift away from the sun.

The compromise reached in 1972 was the leap second. Whenever the difference between UTC and Earth-based time approaches 0.9 seconds, the International Earth Rotation Service announces an upcoming insertion. The next minute on the boundary day gains an extra second.

How a leap second appears on a clock

The standard representation is 23:59:60. A clock that respects the rule will tick:

23:59:58
23:59:59
23:59:60   ← leap second
00:00:00

23:59:60 is a perfectly legal UTC timestamp. It is also a value that many programs assume cannot exist.

Why software breaks

A 60-second minute violates a deep assumption. Some examples of what has gone wrong:

• 2012-06-30: a leap second triggered a Linux kernel bug that caused live-locks in the high-resolution timer code. Reddit, LinkedIn, Yelp, and FourSquare all suffered outages.
• 2015-06-30: Twitter, Apple’s CDN, and Mozilla’s CrashReporter saw issues. The kernel had been patched, but applications had not.
• 2016-12-31: Cloudflare’s load balancer crashed because a Go function returned a negative number when it computed the duration between two timestamps that straddled the leap second.

The pattern is the same across incidents: a time_t value or a duration calculation produces an unexpected number, and a downstream system that assumed monotonicity panics.

How modern systems handle it

The mainstream answer is leap smearing. Instead of inserting a single 23:59:60 second, you slow the clock down by tiny amounts over many hours so the extra second is absorbed gradually. A typical implementation smears the second across the 24 hours surrounding midnight UTC.

Smearing means:

• No timestamp ever has the value 23:59:60.
• Two systems that smear at slightly different rates will disagree about the absolute time during the smear window — but only by milliseconds.
• After the smear ends, all clocks are back in sync.

Google introduced this approach in 2008 and published the rationale in 2011. AWS and Cloudflare have adopted similar policies. Linux kernels offer it as a configuration option (CLOCK_TAI, adjtimex).

The downside: if you compare a smeared clock to a non-smeared one (for example, GPS time), they will disagree during the smear. Whether this is acceptable depends on your application.

The vote to abolish leap seconds

In November 2022, the General Conference on Weights and Measures voted to discontinue leap seconds by 2035. The decision is largely a recognition that:

1. The cost of correctness — outages, special-case code, hours of engineering time per insertion — exceeds the practical benefit of staying within 0.9 seconds of solar time.
2. The Earth’s rotation has actually been speeding up recently, raising the unprecedented possibility of a negative leap second, which would skip a value in the second-of-minute range and would be even more confusing.
3. Astronomical applications that need true Earth time can use UT1 directly.

Until 2035, leap seconds remain the rule. Software that needs to handle them correctly should either smear, use a leap-second-aware time library, or rely on TAI internally and only convert to UTC at the display layer.

A practical takeaway

When you store timestamps:

• Prefer UTC seconds since the Unix epoch for storage. The Unix time_t value is technically not aware of leap seconds, but it is what every database and language understands.
• Avoid the assumption that two consecutive timestamps differ by exactly the number of seconds on a wall clock. They almost always do; on the boundary of June 30 or December 31, they sometimes do not.
• If your application is sensitive to sub-second timing across the leap-second boundary, run NTP with leap smearing or switch to TAI internally.

Leap seconds are a niche concern. When they bite, however, they tend to take down the most-trusted systems — precisely because those systems were designed assuming time is simple.