Leap second

A leap second is a one-second adjustment occasionally added to (or theoretically removed from) UTC to keep atomic time within 0.9 seconds of solar time. Earth’s rotation isn’t perfectly regular — tidal friction is slowly slowing the planet down, and seasonal variations introduce smaller wobbles. Atomic clocks tick at a perfectly steady rate; the planet doesn’t.

Since 1972, 27 leap seconds have been inserted. They always land at midnight on June 30 or December 31 UTC. The minute containing the leap second has 61 seconds (or, theoretically, 59 if a leap second were ever removed — which has never happened).

Leap seconds are deprecated. In 2022 the General Conference on Weights and Measures voted to abandon the practice by 2035, after decades of operational pain in computing systems. After deprecation, UTC will drift slowly away from solar time — at the current rate, by about a second per few decades.

Most software handles leap seconds via “smearing” — gradually adding milliseconds to clock ticks over several hours. Google and Cloudflare publish their smear algorithms; AWS uses a 24-hour linear smear centred on the leap event. POSIX time (the basis of Unix timestamps) pretends leap seconds don’t exist at all — a Unix timestamp can never refer to the leap second itself, which means timestamps near midnight on a leap-insertion day are ambiguous if interpreted strictly.

Why deprecation is happening: high-frequency trading, GPS, and distributed databases all assume time moves monotonically forward at a steady rate. A leap second breaks that assumption. The 2012 leap second caused outages at Reddit, LinkedIn, Mozilla, Qantas’ reservation system, and a number of Linux servers where a kernel bug caused CPU spinlocks. The 2015 leap second was less destructive only because the industry spent three years preparing for it. Astronomers, who actually want UT1 (solar time), have argued against deprecation, but they’ve lost: the future of civil time is a steadily diverging atomic time, with any Earth-rotation reconciliation pushed to a much larger unit (a “leap minute” centuries from now is the working proposal). Reference: BIPM CGPM 2022 Resolution 4.

Worked example

The most recent leap second was inserted at the end of 2016-12-31 23:59:60 UTC. In a strict ITU-R sequence the seconds went 23:59:58 → 23:59:59 → 23:59:60 → 00:00:00. Under Google’s 20-hour linear smear, the same wall-clock interval saw every second stretched by 1/72000 — so a server doing 1000 ops/second produced 999.986 ops/second through the smear window without ever observing a 61-second minute. The Unix timestamp went from 1483228799 (23:59:59) directly to 1483228800 (00:00:00) on POSIX systems, meaning the leap second has no representable timestamp and any event that occurred during it is reported as one of the two adjacent seconds.

When and why it matters

If you build any system that orders events by timestamp (databases, audit logs, distributed consensus protocols like Raft and Paxos), a backward-jumping or stalling clock can violate invariants you didn’t know existed. The 2012 leap second exposed a Linux kernel bug where hrtimer handling deadlocked, causing CPU lockups across Reddit, Mozilla, and significant chunks of the Java ecosystem (Cassandra and Hadoop nodes hung simultaneously worldwide). The defensive playbook today: prefer CLOCK_MONOTONIC for elapsed-time measurement (immune to leap seconds and NTP step changes), use a smearing NTP source like time.google.com for wall-clock reads, and assume any timestamp you receive from a third party may be slightly off across a known leap-second boundary. Reference: RFC 8633 — Network Time Protocol Best Current Practices.