A leap second is a one-second adjustment added to UTC to keep it aligned with astronomical time (UT1) — but it's also a recurring software disaster, because most systems assume 60 seconds per minute and have historically crashed, created duplicate timestamps, or consumed 100% CPU when the 61st second arrived
The previous articles on this site covered time unit basics, milliseconds to years, computing time precision and NTP, atomic clocks and GPS, and the 10,000 hours to work-years context. This article addresses leap seconds, their engineering consequences, and the decision to abolish them — specifically the technical problems they cause in distributed systems and why the ITU voted in 2022 to stop adding them by 2035.
Why leap seconds exist: two different definitions of "a second"
Atomic time (TAI — International Atomic Time) counts seconds using caesium-133 atomic resonance — 9,192,631,770 oscillations per second, extremely stable and consistent.
Astronomical time (UT1 — Universal Time 1) is based on Earth's rotation — specifically, the time for the Earth to complete one rotation relative to the stars. Earth's rotation is not perfectly stable — it slows slightly due to tidal friction from the Moon and other factors, and occasional earthquakes and ice sheet movement can also affect it.
The divergence: over decades, TAI and UT1 drift apart. Without correction, clocks would slowly drift away from alignment with the solar day — noon UTC would gradually move away from when the Sun is at its highest.
UTC (Coordinated Universal Time) was designed as a compromise: it counts seconds using atomic time (stable, predictable) but is kept within 0.9 seconds of UT1 by inserting leap seconds when needed. Since 1972, 27 leap seconds have been added.
How leap seconds are inserted: the 23:59:60 problem
A leap second is announced by the IERS (International Earth Rotation and Reference Systems Service) with about 6 months' notice. It's inserted at the end of June 30 or December 31 UTC:
- 23:59:57
- 23:59:58
- 23:59:59
- 23:59:60 ← the extra second
- 00:00:00 (next day)
The problem: the second 23:59:60 doesn't exist in normal timekeeping. Most software, operating systems, and databases represent time as "seconds since epoch" (Unix timestamps) and assume 60 seconds per minute. When the clock shows 23:59:60, most implementations:
- Return an error or represent it incorrectly
- Allow the clock to show 23:59:59 twice (the NTP "smearing" approach)
- Or crash
The 2012 Linux kernel leap second bug: a case study
When the leap second was inserted on June 30, 2012, a bug in the Linux kernel's hrtimer subsystem caused CPUs to spin at 100% on systems that were running when the leap second occurred. The bug caused servers running Linux to consume maximum CPU on a kernel timer task — effectively taking them offline without crashing.
Companies affected: Reddit, Yelp, LinkedIn, Gawker, and many others reported production outages in the minutes following the 2012 leap second. The fix was to restart the ntpd service (which reset the kernel timer state).
The root cause: the hrtimer subsystem wasn't correctly handling the 61-second minute — a code path that was only triggered once per several years and had a latent bug that went undetected between leap second events.
NTP smearing: making the extra second disappear gracefully
The Google time smear and the AWS time smear are approaches where the extra second is distributed across a period before and after the leap second — instead of inserting a 23:59:60 second, the system runs the clock very slightly slower for several hours on either side of the event.
Google's approach (24-hour smear): starting 12 hours before the leap second and ending 12 hours after, the clock runs at 1/86400 slower — imperceptibly slow, but accumulating exactly 1 second of "extra" time across the 86,400 seconds of the smear window.
The result: no 61-second minute, no 23:59:60, no clock rollback. Systems time-synced to Google's or AWS's NTP pools don't see the leap second at all — they just run through midnight without incident.
The downside: during the smear window, clocks synced to different sources may disagree. A system synced to Google's time and a system synced to a non-smearing stratum-1 server will differ by up to 0.5 seconds during the smear window — potentially causing issues in distributed systems that require tight time synchronization.
The 2022 ITU decision: abolishing leap seconds by 2035
In November 2022, the International Telecommunication Union (ITU) voted to abandon leap seconds before 2035. Instead of continuously adjusting UTC to track UT1, the plan is to allow the two time scales to diverge — up to a maximum difference of about 1 minute — for potentially hundreds of years, at which point a single larger adjustment ("leap minute") might be needed.
The technical motivation: the engineering community overwhelmingly supports abolition. Leap seconds cause recurring distributed systems problems, require special handling in every time synchronization implementation, and the long-term trend of Earth's rotation is uncertain enough that the frequency of future leap seconds was unpredictable.
The astronomical community's concern: over long timescales (centuries), without correction, noon UTC would drift from the solar noon — though this drift would take centuries to become noticeable without timekeeping aids.
How to use the Time Converter on sadiqbd.com
- For duration calculations involving historical dates: be aware that leap seconds mean "the number of seconds between these two timestamps" is not simply end_unix − start_unix for times spanning 1972-present if atomic precision matters — TAI and Unix time diverge by 27 seconds (the accumulated leap seconds)
- For converting between units: straightforward unit conversions (hours to minutes, days to weeks) are unaffected by leap seconds — only conversions involving absolute timestamps around midnight UTC at June/December year-end are affected
- For high-precision systems: if building systems where sub-second precision around midnight UTC matters, document your leap second handling strategy explicitly
Frequently Asked Questions
If leap seconds are being abolished, what happens to the 27 seconds that TAI is already ahead of UTC? Nothing immediately — the 27-second gap between TAI and UTC persists. The abolition decision means no new leap seconds will be added (after some final few that may occur before 2035), not that existing ones will be removed. TAI will continue to run 27 seconds ahead of UTC indefinitely. The expected future drift between UTC and UT1 will be managed differently — most likely a single large adjustment at some point in the distant future when the accumulated difference becomes operationally meaningful, though the exact mechanism hasn't been finalized.
Is the Time Converter free? Yes — completely free, no sign-up required.
Try the Time Converter free at sadiqbd.com — convert between seconds, minutes, hours, days, and years instantly.
