When the Earth Slows Down
Atomic clocks are extraordinarily precise — they lose about one second every 300 million years. The Earth's rotation, however, is not constant. Tidal friction from the Moon gradually slows it down, and geological events can speed it up or slow it down unpredictably. Over decades, this causes International Atomic Time (TAI) — which counts seconds perfectly — to drift ahead of UT1, which tracks the actual rotation of the Earth.
To keep UTC (the civil timekeeping standard) within 0.9 seconds of UT1, the International Earth Rotation and Reference Systems Service (IERS) periodically inserts a leap second: a 61st second added to the last minute of June 30 or December 31. The clock reads 23:59:58 → 23:59:59 → 23:59:60 → 00:00:00.
As of 2024, 27 leap seconds have been inserted since 1972. TAI is currently 37 seconds ahead of UTC.
Why This Breaks Software
The timestamp 23:59:60 is illegal in most time representations. POSIX time (Unix timestamps) explicitly does not model leap seconds — it defines a day as always having exactly 86,400 seconds. When a leap second occurs, POSIX time either repeats a second (the same Unix timestamp occurs twice) or the OS kernel inserts the extra second in a way that confuses applications.
The 2012 Incident
On June 30, 2012, a leap second triggered a bug in the Linux kernel's hrtimer subsystem. The kernel attempted to insert the extra second and corrupted internal timer state. The result: a CPU spin-lock that caused 100% CPU usage across any process that called clock_nanosleep() or futex() — which includes the JVM. Reddit, Yelp, LinkedIn, Mozilla, and dozens of other sites experienced outages lasting hours. The fix required rebooting affected servers.
The Solution: Leap Second Smearing
Rather than inserting a discrete 61st second, cloud providers and large infrastructure operators "smear" the extra second across a window of time — typically the 24 hours surrounding midnight UTC.
During a smear, every second is made slightly longer. For a 24-hour smear of one leap second:
Normal second length: 1.000000000 seconds
Smeared second length: 1.000011574 seconds (= 86401/86400)
The clock progresses from 23:59:59 directly to 00:00:00 — no :60 timestamp ever appears. By the end of the smear window, the clock has accumulated exactly one extra second and is back in sync with UTC.
Google pioneered this approach and has used it since 2008. AWS, Azure, and Meta all use variants of leap smearing today. If your servers use time.google.com or AWS's time service, you are already protected — you will never see a :60 timestamp.
The Catch
During the smear window, your servers' clocks are intentionally wrong by up to 500ms (for a 24-hour smear). For most applications this is irrelevant. For systems that need to correlate events with external parties who are not smearing (e.g., financial exchanges, GPS systems, some government infrastructure), this can cause ordering anomalies. Know your environment.
SRE interviews at large companies frequently ask: "How does Google handle leap seconds, and why?" The answer demonstrates understanding of both the technical failure mode (the 2012 kernel bug, POSIX's 86400-second day assumption) and the engineering trade-off (smearing introduces intentional inaccuracy during the window, but eliminates the risk of application crashes). Follow up by noting that smearing creates a brief period where your clocks disagree with non-smearing systems — relevant for financial or regulatory contexts.