The End of Leap Seconds Explained: What Continuous UTC Means for Your Code

Code that trusts the wall clock, the time of day your computer reports, starts to misbehave. Events sort in the wrong order and durations can turn negative. The end of leap seconds, decided in October 2026, removes one cause of this from 20 May 2027.

A real case: at midnight UTC on 1 January 2017, a leap second hit Cloudflare's DNS software, which turns website names into addresses. It measured some response times as negative, and a random-number function panicked on the negative input. At peak, about 0.2 percent of its DNS queries were affected.

Picture a common setup. A payments team runs a settlement service that records shop payments, about 3 lakh (300,000) a day, and pays shops each night. Its servers sync their clocks with chrony, a common Linux time program. The service sorts payments by wall-clock time and times each gateway call by subtracting two wall-clock readings. The setup is made up, but the problem is real.

When the news broke, the team asked one question: can we now delete our leap-second code? The answer is no, and the reasons show what to fix first.

• UTC (Coordinated Universal Time): the reference time your servers, phones and logs follow.
• TAI (International Atomic Time): a smooth count kept by atomic clocks. UTC ticks at the same rate and is currently exactly 37 seconds behind it.
• UT1: time measured from Earth's rotation, which speeds up and slows down slightly.
• Leap second: one second added to or removed from UTC to keep it close to UT1.
• Wall clock: the time of day your computer reports, such as time.time() in Python. It can be set back.
• Monotonic clock: a separate counter that only moves forward, made for measuring durations.
• NTP (Network Time Protocol): how most servers set their clocks from time servers. chrony is a popular NTP program on Linux.
• PTP (Precision Time Protocol, IEEE 1588): a more precise way to sync clocks over a network.
• Unix time, or POSIX time: seconds counted since 1 January 1970, the way most programs store a timestamp.

The end of leap seconds is a decision to stop inserting or removing seconds in UTC. Resolution 5 of the 28th CGPM says continuous UTC becomes effective on 20 May 2027. The CGPM (General Conference on Weights and Measures) is where member states agree on measurement standards.

The resolution sets the maximum gap between UT1 and UTC, written UT1-UTC, at 3,600 seconds, one hour. It says this keeps UTC continuous for several centuries.

In 2022, the 27th CGPM had decided to raise that limit in, or before, 2035. Resolution 5 notes formal statements from ITU-T (telecom standards), URSI (radio science), IEEE 1588 working groups and industry. They asked to bring continuous UTC forward, to avoid a negative leap second.

A leap second is a one-second adjustment to UTC so atomic time does not drift too far from Earth's rotation. Under ITU-R Recommendation TF.460-6, one was applied when UT1-UTC was predicted to approach 0.9 seconds.

Think of a school clock that keeps perfect time while the sun keeps a slightly uneven schedule. Now and then, someone holds the clock's hand for one second so noon still matches the sun. Where the picture breaks: a held hand only pauses, but a computer clock that is set back replays a second it already showed.

The IERS announces leap seconds in its Bulletin C. Its leap-second list is bundled in the IANA time zone database, which Linux systems install as the tzdata package. It shows 27 since 1972, all added and none removed. The last came at the end of 2016, and UTC has been 37 seconds behind TAI since 1 January 2017.

They broke software because most code assumes every minute has 60 seconds and time only moves forward. A leap second breaks both, and only on rare nights, so those code paths were seldom tested.

The CGPM's own reasons

The 2022 resolution says leap seconds create discontinuities, meaning sudden jumps, that risk serious malfunctions in critical digital infrastructure. Its examples are satellite navigation, telecoms and energy transmission. It adds that network and satellite operators apply leap seconds in different ways that follow no agreed standard.

The risk of a negative leap second

Recent measurements of Earth's rotation suggested that a first negative leap second, which removes a second, may be needed. The 2022 text says this has never been foreseen or tested.

Resolution 5 cites a March 2025 workshop of time experts and the IERS that put its probability at 30 percent by 2035. Continuous UTC from May 2027 removes that risk.

Pause and predict: a gateway call that crosses midnight

A gateway call starts at 23:59:59.6 by the wall clock and really takes 0.6 seconds. At midnight, the kernel sets the clock back one second. What duration does end time minus start time report?

We simulated this step in Python. The wall-clock subtraction reported minus 0.4 seconds, while a monotonic clock reported 0.6 seconds. Four payments half a second apart got two pairs of identical labels, so sorting by label mixed up their order.

What just happened? The end reading came from the replayed second, so it looked earlier than the start. That is the class of bug that hit Cloudflare, whose code assumed time cannot go backwards.

Software steps the clock, slews it, smears it or ignores the leap second. Each choice trades a sudden jump for a spell of being slightly wrong.

Stepping and slewing

Stepping means the clock jumps. In chrony's default system mode, the kernel, the core of the operating system, steps the clock back one second when it reaches 00:00:00 UTC. On Linux, that means 23:59:59 happens twice.

Slewing means the clock runs slightly faster or slower until it is correct again. chrony's slew mode starts at 00:00:00 UTC. Its default maximum rate is 83,333 ppm (parts per million, one twelfth), so on Linux the correction takes 12 seconds.

Smearing

A leap smear spreads the extra second over minutes or hours, so clocks never jump. Google's public time service documents a 24-hour linear smear from noon to noon UTC. Its clocks run about 11.6 ppm slow during it.

Check the number yourself: 1 second spread over 86,400 seconds is 11.574 ppm, about 11.6 microseconds per second. At the leap, smeared time is just under 0.5 seconds behind UTC.

Google calls this its proposed standard smear and says AWS uses the same one. Its page also lists others, such as Bloomberg's 2,000-second smear after the leap. So two fleets that both smear can still disagree during the window.

Unix time ignores leap seconds because POSIX, the standard behind it, counts every day as exactly 86,400 seconds. A day with 86,401 seconds has nowhere to put the extra one. By the POSIX formula, 23:59:60 gets the same number as the next midnight.

The standard also leaves the link between this count and real UTC unspecified. That leaves systems free to step, slew or smear. You can see the clash in a few lines of Python.

import calendar
from datetime import datetime

# The real leap second at the end of 2016, as a UTC time tuple
leap_second = (2016, 12, 31, 23, 59, 60, 0, 0, 0)
next_midnight = (2017, 1, 1, 0, 0, 0, 0, 0, 0)

print(calendar.timegm(leap_second))    # 1483228800
print(calendar.timegm(next_midnight))  # 1483228800, the same number

try:
    datetime(2016, 12, 31, 23, 59, 60)
except ValueError as err:
    print("datetime rejects second 60:", err)

On Python 3.13, both timegm lines print 1483228800, and datetime raises a ValueError that says second must be in 0..59. Yet time.strptime accepts second 60, so parsed logs can carry it straight into this collision.

What just happened? Two different instants got one number. The two collisions also differ: the POSIX formula folds 23:59:60 into midnight, while the Linux kernel replays 23:59:59. Either way, two payments a second apart could share a Unix timestamp.

From 20 May 2027, UTC simply keeps counting with no inserted or removed seconds. Every minute will have 60 seconds, and UTC will stay a fixed whole number of seconds from TAI.

What grows instead is the gap to Earth's rotation, which may reach one hour. Users of UT1 can find UT1-UTC in satellite navigation messages and from the IERS and national measurement institutes.

Radio time signals also carry UT1-UTC, and ITU-R, the radio arm of the International Telecommunication Union, is studying how to update that code. Its Resolution 655 gives radio systems a transition period until 2035, or no later than 2040 where old equipment cannot be replaced sooner.

Beginners can stop here: you know what changed, why and when. The rest is for engineers who run servers or write code that reads clocks.

No, not on the strength of the resolution alone. It changes UTC, but gives no instructions for operating systems, NTP programs or PTP.

Your software must still read old timestamps correctly. Any conversion between UTC and TAI for past dates needs the historic table of 27 leap seconds.

A sensible rule for the team: change no time-sync settings until their makers publish guidance, but fix code that trusts the wall clock now.

Use the monotonic clock for durations, a sequence number for order and the wall clock only as a label. On Linux, Python's time.time() reads CLOCK_REALTIME, which jumps when the clock is stepped. time.monotonic() reads CLOCK_MONOTONIC, which does not.

The monotonic clock still bends during a slew or smear

The Linux clock_gettime manual says CLOCK_MONOTONIC ignores jumps but is affected by frequency adjustments. Python's documentation agrees: its adjustable flag does not cover gradual NTP rate changes.

So when chrony slews, or follows a smearing server, measured durations stretch too. During a 24-hour smear, a 3-second timeout is off by about 35 microseconds. During chrony's 12-second slew, our arithmetic from its one-twelfth rate gives up to 0.25 seconds.

That is harmless for most timeouts, but not for benchmarks or rate limits measured across midnight. CLOCK_MONOTONIC_RAW skips frequency adjustments, so it also skips the corrections that keep it accurate.

CLOCK_TAI can be 37 seconds wrong

Linux also offers CLOCK_TAI, a clock meant to run on atomic time. It is only right if something sets the kernel's TAI offset. chrony's documentation says it sets that offset only when it has a leap-second source and uses its system leap mode.

On our test machine, with no time program running, CLOCK_TAI minus the wall clock printed 0 seconds. A server where chrony set the offset should print 37. The last check in the next section shows how to look.

Check where your code assumes something about time, then check your time servers. These checks come from known failure modes, not from any vendor's migration plan.

1. 1

   Find wall-clock durations

   Search for code that subtracts two wall-clock readings, such as time.time() or Date.now(). Replace them with time.monotonic() or your language's monotonic clock.

2. 2

   Order by sequence, not time

   Order money, logs and events with a database sequence number or another counter, not the wall clock alone.

3. 3

   List your time servers

   List every NTP server your fleet uses and note which ones smear. Do not mix smeared and unsmeared servers in one fleet.

4. 4

   Check chrony's leap settings

   If you run chrony on Ubuntu 24.04, its default chrony.conf reads leap seconds from right/UTC, a time-zone file that counts leap seconds. Its own comment says to remove that line when your servers serve smeared time.

5. 5

   Check the leap-second file

   Look at the expiry date of the leap-second file in your tzdata package. Keep tzdata, and tzdata-legacy where chrony reads right/UTC, updated on every server and container image.

6. 6

   Keep a replay test

   Real leap nights will not test your code after 2027. Keep a test that steps a fake clock back one second.

# 1. Which clock does Python's monotonic use, and can it jump?
python3 -c "import time; print(time.get_clock_info('monotonic'))"
# namespace(implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, adjustable=False, resolution=1e-09)

# 2. Does chrony read leap seconds from right/UTC? (Ubuntu 24.04 default)
grep leapsectz /etc/chrony/chrony.conf
# leapsectz right/UTC

# 3. Is a leap second pending right now?
chronyc tracking | grep Leap
# Leap status     : Normal

# 4. When does the leap-second file expire?
grep '^#expires' /usr/share/zoneinfo/leapseconds
# #expires 1814140800 (2027-06-28 00:00:00 UTC)

# 5. Is the kernel's TAI offset set? (seconds)
python3 -c "import time; print(round(time.clock_gettime(time.CLOCK_TAI) - time.time()))"
# 0 on our test machine; 37 expected where chrony has set the offset

We checked these with Python 3.13.16 and with Ubuntu 24.04's own Python 3.12.3, which printed the same. chrony 4.5 and tzdata 2026c came from Ubuntu 24.04. The expected output follows each command. The TAI check printed 0 on our test machine, where no time program was running.

Here is the settlement step rewritten that way. We ran it with a fake gateway, then again with time.time patched to step back one second. The paid_at labels went out of order; the sequence numbers did not.

import itertools
import time

SLOW_CALL_SECONDS = 3.0
next_seq = itertools.count(1)  # stand-in for a database sequence


def settle_payment(charge, payment, ledger):
    paid_at = time.time()       # wall clock: a label for people, can repeat
    start = time.monotonic()    # never goes backwards, use it for durations
    receipt = charge(payment["id"], payment["amount_rupees"])
    took = time.monotonic() - start

    if took > SLOW_CALL_SECONDS:
        print(f"Slow gateway call for {payment['id']}: {took:.2f} s")

    # Order rows by the sequence number, never by paid_at
    ledger.append({"seq": next(next_seq), "paid_at": paid_at, "receipt": receipt})
    return receipt


def fake_charge(payment_id, amount_rupees):
    time.sleep(0.05)
    return f"rcpt-{payment_id}"


ledger = []
for i in range(3):
    settle_payment(fake_charge, {"id": f"p{i + 1}", "amount_rupees": 499}, ledger)
print([row["seq"] for row in ledger], [row["receipt"] for row in ledger])

It matters because code that converts between UTC and TAI for past dates needs a leap-second table. On Linux, that table ships in the tzdata package. chrony 4.6 and later can read it directly with leapseclist; every version, including Ubuntu 24.04's chrony 4.5, can read it through right/UTC with leapsectz.

The file carries an expiry date, typically a bit under a year after its last update. The copies in tzdata 2026c to 2026e, updated through Bulletin C 72, say they expire on 28 June 2027. Copies in tzdata 2026a and 2026b expire on 28 December 2026, before continuous UTC begins.

How the IERS will set that date once leap seconds stop is undocumented as of 19 October 2026. Keep tzdata updated, and test what your own tools do with an expired file.

Treat it as a short case study showing that wall time can jump.

1. 1

   Define the problem

   A leap second kept UTC near Earth's rotation, so one minute could have 61 seconds.

2. 2

   Name the failure

   Stepped clocks repeated a second, so timestamps collided and durations went negative.

3. 3

   Compare the fixes

   Stepping jumps, slewing corrects over seconds and smearing spreads the second over minutes or hours. Every machine in a fleet must make the same choice.

4. 4

   State the 2026 decision

   Resolution 5 of the 28th CGPM makes UTC continuous from 20 May 2027, allowing up to one hour of gap to UT1.

5. 5

   Give the design rules

   Use monotonic clocks for durations, sequence numbers or logical clocks (counters that only go up) for order, and one time-source policy.

6. 6

   Show the deeper detail

   Mention that a slew or smear also bends the monotonic clock on Linux, so durations across midnight are only approximately right.