Leap Seconds Explained

The /learn/utc-explained article introduces leap seconds as one of UTC's two ingredients (TAI + leap seconds). This article goes deeper: the physical reason leap seconds are needed, the IERS decision process, the 27-leap-second history, the operational bugs, the leap-smear mitigations, and the 2035 abolition mandate.

What a leap second actually is

UTC is defined as TAI (International Atomic Time) minus an accumulated count of leap seconds. As of 2026:

UTC = TAI - 37 seconds

That 37-second offset includes a 10-second baseline at the January 1, 1972 introduction of UTC plus 27 leap seconds inserted since.

A leap-second insertion takes the form of an unusual UTC second numbered 23:59:60, appearing once between 23:59:59 and 00:00:00 at the end of UTC June 30 or December 31. For one second, the UTC time-of-day shows:

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

The next UTC day proceeds normally. The cumulative effect: UTC fell one second behind TAI at that moment, restoring alignment with UT1.

Negative leap seconds (deletions, where a UTC second is skipped) are also defined by the standard but have never been inserted. The expected next leap second was discussed in 2022 as potentially a negative one (because Earth had been rotating slightly faster than predicted), but it didn't materialize.

Why Earth's rotation needs correcting

UT1 (Universal Time 1) is the astronomical timescale based on Earth's actual rotation. Modern UT1 is computed from Very Long Baseline Interferometry (VLBI) observations of distant quasars by the International VLBI Service for Geodesy and Astrometry, with the IERS in Paris publishing the results.

UT1 fluctuates on several timescales:

• Long-term: tidal friction between Earth and Moon slows the rotation, lengthening the day by about 2.3 milliseconds per century averaged over millennia. The Moon is moving away from Earth at ~3.8 cm per year, exchanging angular momentum.
• Decadal: irregular variations of ~10 milliseconds over decades, attributed to angular-momentum exchange between Earth's liquid outer core and the solid mantle.
• Annual: a ~30-millisecond cycle from atmospheric mass redistribution (winter vs summer winds, snow vs no snow).
• Sub-daily: ~1-millisecond variations from ocean and atmospheric tides.

The accumulated drift is what triggers leap seconds: when TAI (constant atomic rate) gets more than 0.9 seconds ahead of UT1 (Earth-rotation rate), a leap second is added to push UTC closer to UT1.

The complete 1972–2026 leap-second list

| Date inserted (UTC) | Cumulative leap seconds | TAI − UTC | | -------------------------- | ----------------------- | --------- | | Initial state, 1972 Jan 1 | 0 | 10 s | | 1972 Jun 30 | 1 | 11 s | | 1972 Dec 31 | 2 | 12 s | | 1973 Dec 31 | 3 | 13 s | | 1974 Dec 31 | 4 | 14 s | | 1975 Dec 31 | 5 | 15 s | | 1976 Dec 31 | 6 | 16 s | | 1977 Dec 31 | 7 | 17 s | | 1978 Dec 31 | 8 | 18 s | | 1979 Dec 31 | 9 | 19 s | | 1981 Jun 30 | 10 | 20 s | | 1982 Jun 30 | 11 | 21 s | | 1983 Jun 30 | 12 | 22 s | | 1985 Jun 30 | 13 | 23 s | | 1987 Dec 31 | 14 | 24 s | | 1989 Dec 31 | 15 | 25 s | | 1990 Dec 31 | 16 | 26 s | | 1992 Jun 30 | 17 | 27 s | | 1993 Jun 30 | 18 | 28 s | | 1994 Jun 30 | 19 | 29 s | | 1995 Dec 31 | 20 | 30 s | | 1997 Jun 30 | 21 | 31 s | | 1998 Dec 31 | 22 | 32 s | | 2005 Dec 31 | 23 | 33 s | | 2008 Dec 31 | 24 | 34 s | | 2012 Jun 30 | 25 | 35 s | | 2015 Jun 30 | 26 | 36 s | | 2016 Dec 31 | 27 | 37 s |

Notable patterns:

• 1972–1979: a leap second nearly every year (9 in 8 years), reflecting accumulated rotational drift not corrected before UTC's introduction.
• 1999–2004: zero leap seconds for over five years, the longest gap before 2017. Earth was rotating slightly faster than expected.
• 2017–2026: zero leap seconds for nine years, the longest gap on record so far. Earth has been rotating faster than predicted; some IERS analyses in 2022 suggested a negative leap second might be needed by the late 2020s.

The IERS Bulletin C process

The decision to insert (or delete) a leap second is made by the IERS (International Earth Rotation and Reference Systems Service) in Paris, based on continuous monitoring of UT1.

Bulletin C is the leap-second announcement publication. It's issued twice yearly (January and July) and announces leap-second decisions for the next six months. A typical Bulletin C either:

• Announces a leap second: “A positive leap second will be introduced at the end of June (or December).”
• Confirms no leap second: “No leap second will be introduced.”

The six-month forward notice gives operating systems, network time servers, satellite operators, broadcasters, and other dependent infrastructure time to prepare. NTP servers distribute leap-second flags in advance; modern operating systems (Linux, BSDs, macOS, Windows) update their leap-second tables.

The 2012 incident

The June 30, 2012 leap second caused the largest documented leap-second outage. The technical cause: a bug in the Linux kernel (versions ~3.0–3.4) in the high-resolution timer subsystem. When the leap second was inserted, the hrtimer subsystem set a flag that caused futex_wait calls to wake in a tight loop, consuming 100% CPU and preventing further progress.

Java applications using NTP-synchronized clocks — common in big-data and search infrastructure — were particularly hit because the JVM relied heavily on futex_wait for synchronization. Cassandra and Hadoop clusters hung on affected nodes. MySQL servers showed similar symptoms.

Documented outages on June 30 / July 1, 2012:

• Reddit: ~30–40 minute outage. The hosting Cassandra cluster hung; engineers diagnosed and rebooted.
• LinkedIn: brief outage of customer-facing services.
• Mozilla (Hadoop-based infrastructure): outage.
• Foursquare, Yelp, StumbleUpon: brief customer-visible outages.
• Qantas Airlines reservation system: outage affecting check-in.
• Many other enterprises with Linux/Java infrastructure.

The immediate workaround: rebooting affected servers, or running:

date -s "$(date)"

(restating the system date triggered a kernel-state reset that cleared the bug).

The kernel fix was committed shortly after, and modern kernels (3.5+) handle leap seconds correctly.

The 2015 and 2016 leap seconds

The June 30, 2015 leap second went much more smoothly. Linux kernels were fixed, and many platforms had adopted leap smear (see next section). Issues were limited: brief Twitter disruption, isolated AWS users with custom NTP configurations, some Android devices showing wrong time for a few hours.

The December 31, 2016 leap second was the quietest yet — no major outages reported. Most major platforms (Google, Amazon, Meta, Microsoft, Cloudflare) had production-tested leap-smear systems.

No leap second has been inserted since 2016. The 9.5-year gap (as of 2026) is the longest in the IERS record.

Leap smear

Leap smear is the dominant operational solution. The basic idea: instead of inserting a single discontinuous extra second, distribute the 1-second adjustment over a longer window (typically 24 hours), making each second in the window slightly longer (or shorter, for a negative leap second).

Google published its leap-smear approach in 2008. The arithmetic for a 24-hour smear absorbing one positive leap second:

• Smear window: 12 hours before insertion to 12 hours after (specific choice varies by implementation).
• Per-second stretch: 1 second + (1 / 86400) ≈ 1.0000116 seconds.
• Maximum offset during the window: ±0.5 seconds from true UTC.

Properties:

• The smeared clock is strictly monotonic — no discontinuity, no 23:59:60, no rewinding. Applications see a normal time stream.
• The smeared clock is up to 0.5 seconds off from true UTC during the window. Acceptable for most application timestamps; not acceptable for sub-second precision (GPS-augmentation, scientific instruments, financial-trading regulations).
• Different smear windows produce different intermediate times: two services using different smear algorithms will disagree by up to 1 second during the window. This is a subtle bug source — two services that must agree on timestamps need to use the same smear schedule.

Major leap-smear implementations:

• Google Public NTP (time.google.com, etc.) — 24-hour smear centered on the leap second.
• Cloudflare time service — similar.
• AWS Time Sync — 24-hour smear.
• Meta — internal smear (publicly described).
• Microsoft — Windows Server 2019+ supports smear via “UTC” vs “UTC-SLS” configurations.

The IETF describes the “UTC with smoothed leap seconds” (UTC-SLS) approach in RFC drafts; no production protocol mandates a specific smear schedule.

Other mitigation patterns

Alternatives to leap smear:

• Reject the leap second: simply don't apply it in software. Clocks drift 1 second from UTC; usually acceptable for applications that don't care about sub-second precision. Some legacy systems do this.
• Run two clocks: maintain both TAI (no leap seconds) and UTC (with leap seconds) in software; let applications choose. PTP (Precision Time Protocol) works this way internally.
• GPS Time: applications that want a monotonic atomic clock can use GPS Time (which has no leap seconds); GPS Time = UTC + 18 seconds as of 2026.
• Database-managed: store all timestamps as TAI or GPS Time internally; convert to UTC only at presentation. Avoids the smear-disagreement bug class.

CGPM Resolution 4 (2022)

In November 2022, the General Conference on Weights and Measures (CGPM) — the world's highest metrology authority — adopted Resolution 4. The key text: the maximum allowed difference between UTC and UT1 should be increased by or before 2035.

The practical effect: leap seconds will no longer be inserted routinely. UTC will be allowed to drift from UT1 by more than the current 0.9-second tolerance — possibly by minutes — with infrequent (decadal-scale or longer) larger corrections rather than frequent one-second adjustments.

Motivations:

• Operational cost: 2012-class incidents recur with some frequency despite preparation. The 2015 and 2016 insertions still required preparation work across many organizations.
• Industry advocacy: Google, Meta, Microsoft, Amazon, and other major operators have lobbied for abolition for over a decade.
• Scientific neutrality: most astronomical applications use UT1 directly (computed by IERS), not UTC, so abolishing leap seconds in UTC doesn't affect astronomical practice.

Opposition came primarily from a few delegations (notably Russia) citing tradition. The vote was nearly unanimous.

Implementation details — the exact replacement mechanism — are still being worked out by CCTF (Consultative Committee for Time and Frequency) and ITU-R. Likely direction: a UT1-UTC tolerance of 1 minute or more, with larger corrections happening once per few decades.

Common misconceptions

“Leap seconds always happen at midnight.” They happen at the end of UTC June 30 or December 31. In non-zero-offset time zones, that's some other local time. Tokyo (UTC+9) sees the leap-second insertion at 08:59:60 local time the next day.

“GPS receivers handle leap seconds via the satellites.” GPS satellites broadcast GPS Time (no leap seconds) plus the GPS-Time-minus-UTC offset. Receivers compute UTC by subtracting that offset. “Handling” the leap second means correctly displaying the discontinuity in the UTC output, which some receivers do well and some don't.

“Leap seconds and leap years are related.” They're completely unrelated. Leap years (Feb 29 inserted in years divisible by 4 with exceptions) keep the calendar year aligned with the seasonal year. Leap seconds keep UTC aligned with Earth's rotational position. Different scales (years vs seconds), different mechanisms, different sources of drift.

“Earth's rotation is constantly slowing.” The long-term trend is slowing (tidal friction). Short-term, Earth rotates faster or slower unpredictably; decadal variations of ±10 ms accumulate to seconds over centuries. The 2017–2026 gap with no leap seconds reflects Earth rotating slightly faster than predicted.

“Leap smear is part of the UTC standard.” It's not. Leap smear is an operational technique that distributes UTC into a slightly-off but monotonic approximation. The UTC standard (ITU-R TF.460-6) prescribes the 23:59:60 insertion; smear is what practical systems do to avoid the discontinuity.

“After 2035, UTC won't track Earth's rotation.” UTC will still track UT1 — just with a larger tolerance. The expected approach is a tolerance of 1 minute or more, allowing UTC to drift further before a correction. Over millennia, UTC will still be re-aligned to UT1; the correction will just be infrequent.

“The 2012 outage was a UTC bug.” It wasn't — UTC was inserted correctly. The bug was in the Linux kernel's hrtimer subsystem, which had not been thoroughly tested for the 23:59:60 case. The bug was fixed shortly after; modern kernels handle insertions without issue.

“Leap seconds are predictable.” They're announced six months in advance, but the underlying need (UT1 drift) is only loosely predictable. IERS analyses years in advance are heavily revised as Earth's rotation evolves. The 2020s have seen multiple predictions of impending leap seconds (positive or negative) that didn't happen.