What are leap seconds and why are they being phased out?

Earth's rotation isn't perfectly steady. It speeds up and slows down by tiny amounts due to the moon's tidal pull, atmospheric drag, and changes in Earth's mass distribution (glaciers, magma flow, even big earthquakes). Atomic clocks, which define UTC, are perfectly steady. Over years, the two drift apart.

Leap seconds are how we resolve that drift — adding (or theoretically removing) a single second to UTC to keep it aligned with Earth's rotation. They're rare, occasional, and headed for abolition by 2035.

For converting precise timestamps that may include leap seconds, the epoch converter handles standard POSIX (no leap seconds) — which matches what most software does anyway.

How a leap second works

When inserted, a leap second is appended to the end of the last minute of a UTC day, usually December 31 or June 30. The clock reads:

```
23:59:58
23:59:59
23:59:60 ← leap second (yes, this is a real time)
00:00:00
```

That extra "60" second is unusual and breaks naive time-handling code. Most operating systems "smear" leap seconds — slowing the clock by a few microseconds for hours on either side — rather than displaying 23:59:60 directly.

Leap seconds are decided by IERS (International Earth Rotation Service) about 6 months in advance. As of 2026, 27 leap seconds have been added since 1972 (the first one). None has ever been removed (which would mean Earth was rotating fast enough to outpace UTC — possible in theory, hasn't happened in practice).

Why they exist

Two reasons:

1. Astronomy and navigation. Telescopes, ship navigation, and pre-GPS aviation depended on time being aligned with Earth's actual rotation. If UTC drifted away from solar time, sky-position calculations would be wrong.

2. Backward compatibility. UTC was designed to replace GMT in 1972. The expectation was that UTC would stay close to GMT (which was solar-time-based) so existing systems could keep working. Leap seconds were the mechanism for that staying-close.

Why they break software

Leap seconds are well-known software gotchas. A few greatest hits:

- 2012 — Reddit, LinkedIn, Yelp, FourSquare, several airlines all hit issues from a leap second on June 30. Linux's `gettimeofday()` could return the same time twice in a row, breaking assumptions.
- 2015 — Twitter and several other services hit issues from another leap second.
- 2017 — Cloudflare had a partial outage caused by leap second handling in DNS resolution code.

The fix in modern systems: don't expose the leap second to applications. Instead, smear it across hours or days. Google's NTP servers smear over 24 hours. Amazon's smear over 24 hours. Most cloud platforms now hide leap seconds from running code.

Why they're being abolished

The 27th General Conference on Weights and Measures (CGPM 2022) voted to eliminate leap seconds by or before 2035. The vote was unanimous among member nations, with the US, France, Australia, and others as primary advocates.

Reasons for abolition:

- Software pain. As shown above, leap seconds break things. The cost of handling them across global infrastructure exceeds the benefit.
- Limited audience. Astronomy and traditional navigation, which originally needed UTC = solar time, have moved on. Modern GPS and astronomical software use their own internal time scales (TAI, GPS time, UT1) and convert as needed.
- Predictability. Leap seconds are unpredictable — announced 6 months in advance based on Earth's rotation. Eliminating them makes timekeeping fully predictable for the first time.

The exact replacement mechanism is still being worked out. The leading proposal: let UTC drift from solar time freely, and accept that "noon" might be a few minutes off from where the sun is in the sky 100 years from now (acceptable, since DST already shifts the local sun-clock relationship by an hour twice a year).

What happens after 2035

Several scenarios under discussion:

1. Cumulative leap minutes or hours, applied infrequently (every few centuries). UTC mostly free-runs but periodic adjustments happen when the drift gets large.
2. Permanent free-run. No more adjustments. UTC just stops being aligned with solar time.
3. A new time scale (called TAI-based UTC or similar) replaces UTC entirely.

The exact decision depends on negotiations among national time labs (NIST, NPL, BIPM) over the next several years. Best guess: option 1 with very rare adjustments.

What to do as a developer

For the next decade or so, leap seconds are still real. Recommended practice:

- Use a time-smearing NTP source (Google Public NTP, Amazon Time Sync Service, Cloudflare time.cloudflare.com).
- Don't write code that assumes 86,400 seconds per day if you care about precise duration. Instead, use UTC timestamps and let the runtime handle the conversion.
- For high-precision needs (GPS, financial trading, scientific instruments), use a leap-second-aware time source like TAI.

For most application code, ignore leap seconds entirely and use the standard library's UTC functions. They handle it correctly via smearing.

FAQ

When was the most recent leap second?

December 31, 2016. UTC went from 23:59:59 to 23:59:60 to 00:00:00. There hasn't been one since — Earth's rotation has actually been slightly faster than UTC for several years, meaning we'd need a negative leap second (removing a second) to stay aligned. Negative leap seconds have never been applied; the IERS has avoided declaring one.

Could a negative leap second happen?

Theoretically yes. Earth's rotation has been slightly faster than UTC since around 2020. If the trend continues and accumulates enough, IERS may need to declare a negative leap second — the first ever. But the abolition decision (effective by 2035) likely means we'll never see one.

Does Unix epoch include leap seconds?

No. POSIX `time_t` ignores leap seconds entirely — it pretends every day has exactly 86,400 seconds, no exceptions. So a Unix timestamp at "midnight UTC" is technically 27 seconds ahead of what an atomic clock would say. For 99% of uses, this doesn't matter.

How does GPS handle leap seconds?

GPS time has its own scale (no leap seconds, started counting at January 6, 1980). It's currently 18 seconds ahead of UTC. GPS receivers convert internally when they display UTC.

Will my server crash on the next leap second?

Modern Linux kernels and cloud-platform NTP servers handle leap seconds gracefully via time smearing. Older systems (pre-2017) might still misbehave. Test with a smeared NTP source to confirm.

Why don't we just use a steadier reference like atomic time?

Astronomy historically needed UTC ≈ solar time, and UTC was the international standard. Switching to TAI (atomic time, no leap seconds) would have broken backward compatibility. The 2035 abolition is essentially that switch — UTC will remain the standard but stop tracking solar time precisely.

Bottom line

A leap second is an occasional one-second adjustment to UTC, added when Earth's rotation slows enough that UTC drifts from solar time by ~0.9 seconds. They've caused software outages and operational headaches since 1972. The international community has agreed to phase them out by 2035, after which UTC will free-run from atomic clocks without periodic adjustments.

For everyday development, the epoch converter and standard libraries handle this fine — they use POSIX time, which ignores leap seconds entirely.