A Quirky Problem: Leap Seconds

The Earth is Slowing Down

Atomic clocks measure time in perfectly uniform SI seconds. But our calendar is based on the Earth's rotation, which is gradually slowing due to tidal friction from the Moon. Over decades, these two time systems drift apart.

To keep Coordinated Universal Time (UTC) — the global civil time standard — aligned with the actual position of the sun, the International Earth Rotation and Reference Systems Service (IERS) occasionally inserts a Leap Second into UTC. This typically happens at 23:59:59 on June 30th or December 31st. The clock sequence becomes:

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

Since 1972, 27 leap seconds have been added. The next one could come at any time with only six months' notice.

Why Computers Hate Leap Seconds

Most software assumes a minute has exactly 60 seconds and a day has exactly 86,400 seconds. A leap second violates both assumptions. The failure modes are varied and nasty:

• Crash: Some systems encounter 23:59:60 as an invalid timestamp and throw an exception.
• Time jump forward: Some systems round 23:59:60 up to 00:00:00, effectively skipping a second.
• Time going backward: Some systems insert the leap second by repeating 23:59:59 twice. Any code that assumes time is monotonically increasing (always moving forward) will break — log entries appear out of order, timeouts fire early, and distributed locks can expire unexpectedly.
• Linux kernel bug (2012): A leap second triggered a kernel bug that caused massive CPU spin-locking, taking down servers at Reddit, LinkedIn, Mozilla, and others.

The Solution: Leap Smearing

To protect application software, major cloud providers (Google, Amazon, Meta) use Leap Smearing. Instead of inserting the extra second all at once, they slightly slow down their NTP servers for a window of time around the leap second (typically ±12 hours or ±24 hours).

Each physical second during the smear window is stretched by a tiny fraction. The total extra time is distributed across thousands of seconds, so no individual second is noticeably different. Application software never sees a jump, a repeat, or a 61st second — it just sees time advancing slightly slower than usual.

The trade-off: during the smear window, the NTP servers are intentionally reporting a time that is slightly wrong relative to UTC. For most applications this is fine, but it means you cannot mix smeared and non-smeared time sources in the same system.