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 typically runs a millisecond or two longer or shorter than 86,400 atomic seconds.

Over years, those milliseconds accumulate. Before 1972, UTC kept pace with the Earth by slightly adjusting the length of its second and making small step corrections, which was awkward for everyone. Without some correction, clocks based purely on atomic time slowly drift away from the sun.

The compromise reached in 1972 was the leap second: UTC would tick in exact atomic seconds, starting 10 seconds behind International Atomic Time (TAI), and be adjusted in whole seconds to stay within 0.9 seconds of Earth-based time (UT1). When the gap approaches that limit, the International Earth Rotation and Reference Systems Service (IERS) announces an insertion about six months ahead, and the last minute of the chosen day gains an extra second.

Twenty-seven leap seconds have been added since 1972, so TAI is now 37 seconds ahead of UTC. The most recent was inserted at the end of 31 December 2016; none has been scheduled since.

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: problems were smaller and more scattered. The kernel bug had been patched, but some applications and network equipment still mishandled the extra second.
• 2016-12-31: part of Cloudflare’s DNS service failed because Go code computed a negative duration between two timestamps that straddled the leap second, and a function that expected a positive value panicked.

The pattern is the same across incidents: a Unix timestamp (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 Meta have published similar smearing policies. On Linux, smearing is normally done by the time server or NTP daemon (chrony and ntpd can both do it), not by the kernel; the kernel separately offers a CLOCK_TAI clock for programs that want to avoid leap seconds entirely.

The downside: if you compare a smeared clock to one that applies the leap second as a single step, they will disagree by up to a second 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 (CGPM) voted to stop inserting leap seconds by or before 2035, letting the gap between UTC and Earth rotation grow beyond 0.9 seconds. The details of what replaces the rule — and how large the gap may become — are still being worked out. 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, in which a minute would end at 23:59:58 — a case almost no software has ever been tested against.
3. Astronomical applications that need true Earth time can use UT1 directly.

Until the change takes effect, leap seconds remain possible, even though none has been needed since 2016. 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. (For how UTC relates to the older GMT, see UTC vs GMT.)

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.