NTP Leap Second: Abolished from May 2027, Smear & Incidents

The leap second is one of the subtlest and most-dreaded mechanisms in the NTP protocol. Since 1972 it has compensated for the irregularities of Earth's rotation to keep UTC in phase with astronomical UT1. For an NTP server operator, each event has been a rehearsed minor crisis: an announcement to watch, a switchover plan, and hours of log scrutiny afterwards.

This page covers what every NTP operator or administrator needs to know: the origin of the mechanism, the 27 leap seconds added since 1972 and the outages they caused, how NTP signals the event, the two competing approaches (step and smear), how to tell what your upstream servers do, chrony and ntpd behaviour, the policy applied on our servers, and the 15 October 2026 resolution that ends the mechanism on 20 May 2027.

1. Why the Earth forces us to add seconds

UTC (Coordinated Universal Time) has been defined since 1972 as the count of SI seconds produced by an ensemble of atomic clocks. UT1 is the time defined by Earth's actual rotation, measured by VLBI interferometry on distant quasars. The two diverge because Earth's rotation is not regular: tidal friction, redistribution of internal masses, core-mantle interactions. Between 1972 and 2016 the Earth turned on average slightly slower than UTC assumes, and the gap built up at roughly one second every one to two years.

The IERS (International Earth Rotation and Reference Systems Service) monitors this drift and, to keep |UT1 − UTC| below 0.9 seconds, its centre at the Paris Observatory publishes a Bulletin C twice a year, announcing about six months ahead whether there will be a leap second. The event takes place preferably on 30 June or 31 December: the second 23:59:60 is inserted (a 61-second minute), followed by 00:00:00 of the next day.

2. The 27 leap seconds since 1972

From 1972 to end-2016, 27 leap seconds were added. All positive. The five most recent, which the founder of RDEM Systems went through running public NTP servers since 2005:

Since 1 January 2017, the TAI − UTC difference has stayed at 37 seconds. No leap second has been added for 9 years — a historical record, caused by the acceleration of Earth's rotation. The latest bulletin, Bulletin C 72 of 6 July 2026, states it plainly: "NO leap second will be introduced at the end of December 2026". Unix time, for its part, ignores leap seconds: our Unix timestamp converter gives the TAI − UTC offset in force on any date since 1972.

3. What 23:59:60 broke: documented incidents

The NTP protocol has always been able to carry the leap second. What broke, every time, was software that assumed a second never repeats and time never goes backwards. The incidents below are those we could tie to a primary source (operator postmortem, kernel commit, bug tracker) or to technical press citing one.

Two attributions come up often and are wrong. The Zune player freeze of 31 December 2008 was a leap year bug (day 366), not a leap second. The Instagram, Netflix and Pinterest outages of 29-30 June 2012 came from the storm that cut an AWS data centre in Virginia, the same weekend.

4. How NTP signals a leap second (Leap Indicator)

The NTP protocol (RFC 5905, §7.3) reserves the two most significant bits of the packet's first byte for the Leap Indicator (LI) field. It is a warning about the last minute of the current month. Four possible values:

RFC 5905 sets no notice period, and it contradicts itself on the field's scope: its definition speaks of "the last minute of the current month", its Figure 9 of "last minute of the day". RFC 8633 (§3.7) settles it: "RFC 5905 is clear that leap seconds are only applied on the last day of a month". Because some older clients apply the second at the end of the current day, it recommends that servers wait until the last day of the month to announce; that is what NIST does, its servers announcing from 00:00 UTC on that day. ntpd may keep the announcement up for the whole last month. A Stratum 1 server gets the information from its reference (GNSS, DCF77) or from the leap-seconds.list file, published by the IERS and redistributed by the IANA tz database. The file carries a hash (#h) and an expiry date (#@): the current version, updated with Bulletin C 72, expires on 28 June 2027.

5. Step vs smear: two schools

When 23:59:60 arrives, you have to choose what happens system-side:

5.1 The step approach (insert a 23:59:60 second)

Faithful to the definition of UTC: the clock lives a real 61-second minute. On Linux the kernel repeats the last second; this is the default behaviour of chrony (leapsecmode system) and of ntpd. NIST does the same: its servers repeat 23:59:59. Pro: the clock stays strictly aligned with UTC. Con: two seconds carry the same timestamp, and any program that assumes strictly increasing time can get it wrong, as the incidents above showed.

5.2 The smear approach (spreading)

Devised by Google after the 2005 leap second, tested in 2008 and made public in 2011: instead of a one-second jump, the length of each second is changed very slightly for several hours until the whole second has been absorbed. With a 24-hour linear smear, each second lasts about 1.0000115 s, i.e. 11.6 ppm. Pro: no repeated timestamp, no broken timer. Con: during the window the time served is not UTC. A smear centred on the event departs from it by up to half a second; a smear that starts after the event, like Meta's or chrony's, starts one second off.

5.3 Who does what

Apple (time.apple.com) and national laboratories such as PTB do not publish their policy; we do not attribute one to them.

6. Knowing what your upstream servers do

The short answer is uncomfortable: outside a leap second window, nothing in an NTP packet tells you whether a server smears. RFC 8633 states it: "there is no standardized way for a client to detect that a server is using leap smearing". A smearing server does not announce the leap second, and Google keeps LI at 0 permanently. Three sources of information remain.

1. The operator's documentation. Outside an event, you will have nothing else. The table above gathers what operators publish; for the others, the absence of a statement is not an answer.
2. LI during the announcement period. On the last day of the month a compliant server announces the leap second; a smearing server stays at 0. With chrony, chronyc ntpdata gives each source's Leap status, and chronyc tracking the one your server retained (Normal, Insert second, Delete second). With ntpd, ntpq -c rv shows leap=.
3. The offset during the window. Compared with a non-smearing reference, a smearing server drifts progressively by up to several hundred milliseconds. If you have enough compliant sources, it shows in chronyc sources: the smearing source becomes a false ticker.

# What your server retained
chronyc tracking | grep 'Leap status'

# What each source announces (here, one named source)
chronyc ntpdata time.cloudflare.com | grep 'Leap status'

# ntpd
ntpq -c rv | tr ',' '\n' | grep leap

chronyc smoothing does not help here: it describes the local server's smoothing, not its upstreams'.

7. chrony: leapsecmode, leapseclist, smoothtime

Two separate questions, two sets of directives. leapsecmode decides what the server does with its own clock. smoothtime decides what it serves to its clients. Smearing is not a value of leapsecmode.

# /etc/chrony/chrony.conf

# Local clock: let the Linux kernel insert the second (default)
leapsecmode system
# Other values: step (chronyd does the jump), slew (gradual correction,
# about a dozen seconds with the default maxslewrate), ignore

# Local source of the information: the IERS list shipped with tzdata
leapseclist /usr/share/zoneinfo/leap-seconds.list

Smearing is configured separately. The chrony documentation gives this combination; the first line is required, otherwise the local clock's step would reset the smoothing.

# Smear: spread the second over what the server SERVES
leapsecmode slew
maxslewrate 1000
smoothtime 400 0.001024 leaponly

leaponly restricts smoothing to leap seconds: ordinary offsets and drift are not smoothed. With smoothtime 400 0.001024, smoothing starts at 00:00:00 UTC and lasts about 17 hours (62,500 seconds): the frequency rises to 32 ppm then falls back, and the area under that ramp equals the second to absorb. During the window the server stops passing on the announcement, and the time it serves starts one second off UTC, decreasing to zero.

The chrony documentation restricts this option to local networks: clients must have a single smearing server, or several identically configured ones, and must not load any leap second list themselves. On a public server, RFC 8633 forbids it.

8. ntpd: leapfile and announcement

ntpd (reference or NTPsec) reads the same leap-seconds.list file and re-checks it once a day:

# /etc/ntp.conf

# IERS list, redistributed by tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list

When the file is present, ntpd ignores its sources' LI bits and arms the leap second within a month of the deadline. Without the file, it follows the majority of its sources. The file expires: if your distribution does not keep tzdata current, fetch it directly.

0 3 * * 1 wget -q -O /usr/share/zoneinfo/leap-seconds.list https://data.iana.org/time-zones/data/leap-seconds.list

ntpd also has a smearing option, leapsmearinterval, experimental and compiled separately; its documentation warns: "DO NOT USE THIS OPTION ON PUBLIC-ACCESS SERVERS!".

9. Our policy on RDEM servers

• Announcement. Our servers pass the Leap Indicator on to their clients. A client following us receives the announcement and applies the second itself.
• Source of the information. Each server reads leap-seconds.list provided by tzdata, and cross-checks its Stratum 1 sources: national laboratories (Paris Observatory, PTB), Netnod, exchange points depending on the site, and our two Stratum 1 servers, one GPS, the other a GNSS Stratum 1 with Galileo.
• Google among our sources, knowingly. time.google.com is one of the 17 to 20 upstream servers of each of our machines, because it is reliable the rest of the time. During a smear window it would drift progressively away from the others and chrony's selection would discard it as a false ticker: one source against sixteen to nineteen. It never announces the leap second, but that cannot make us miss it: the local list is enough to arm it, whatever the sources vote.
• Negative leap second. chrony can handle it (Delete second), and our servers would apply it like a positive one. Nobody has ever seen one in production: that is precisely the argument behind the 15 October 2026 resolution.
• Your clients. If you want smeared time, smear on your side, on a local server, and do not mix that server with ours.

10. Preparing for an event

The mechanism remains in force until 20 May 2027. Until then, keeping the ability to handle a leap second is still part of NTP hygiene:

1. Check the local source on each server: the directive (leapseclist or leapfile) must point to a file that exists, and grep '^#@' /usr/share/zoneinfo/leap-seconds.list must give a future expiry.
2. Test on a staging server with a list file carrying a near deadline: logs must show the announcement, then the insertion.
3. Document the policy (step or smear) per infrastructure segment, and know what your sources do (section 6).
4. Audit critical applications: any logic doing if (new_ts == old_ts) or assert ts_diff > 0 on the wall clock must move to a monotonic clock.
5. Schedule an observation window if a Bulletin C announces an event: it falls six months later, on 30 June or 31 December.

11. The end of the leap second: the 15 October 2026 resolution

2022, the principle. The 27^th General Conference on Weights and Measures (CGPM) decided, in its Resolution 4, that the maximum value of UT1 − UTC "will be increased in, or before, 2035". It asked the International Committee (CIPM) to propose to the next conference a new value ensuring the continuity of UTC for at least a century, and a schedule. The International Telecommunication Union followed in 2023 (WRC-23, Resolution 655): a tolerance of no less than 100 seconds, implemented "possibly in 2035".

2026, the decision. The 28^th CGPM met from 13 to 15 October 2026 at the Palais des Congrès in Versailles. On Thursday 15 October, it adopted Draft Resolution C, which became Resolution 5, "On the technical actions needed to ensure the continuity of UTC". The text (only the French version is authoritative) decides that:

• "continuous UTC will become effective on 20 May 2027";
• "the maximum value for the difference |UT1-UTC| will be 3 600 seconds (1 hour), ensuring the long term continuity for UTC for several centuries".

The schedule was brought forward from 2035 to 2027 because of the negative leap second, which the resolution considers "to pose a high risk of causing anomalies and disruption to critical infrastructures that are largely unprepared". The CCTF report puts the probability of a negative leap second within ten years at about 30 %, and of a positive one at about 50 %: "to avoid any risk, UTC should be made continuous by 2027".

For NTP, the resolution does not touch the protocol: the Leap Indicator stays defined by RFC 5905, and its value 11 (clock unsynchronized) keeps its use. The leap-seconds.list file still expires on 28 June 2027: on 15 October 2026, the tz database coordinator wrote to the IERS, which maintains the file, asking for the expiry to be dropped or pushed back; as of 16 October, no new version has been published. What chrony, ntpd and operating systems will do with their leap second code has not been announced either. On the compliance side, texts requiring traceability to UTC, such as those of MiFID II for trading venues, refer to UTC, continuous from 20 May 2027. The checks to make before then (local list, leapsectz, file expiry, leap status) are detailed in what changes for your NTP servers by May 2027.

Resources and references

• IERS, Bulletin C — twice-yearly announcement of a leap second or its absence
• leap-seconds.list (IANA) — the IERS list, redistributed by the tz database
• RFC 5905 — NTPv4, Leap Indicator field (§7.3)
• RFC 8633 — NTP best current practices: leap second announcement and ban on smearing for public servers (§3.7)
• chrony.conf documentation — leapsecmode, leapseclist, smoothtime
• CGPM 2022, Resolution 4 — the principle of continuous UTC
• CGPM 2026, Resolution 5 — text adopted on 15 October 2026: continuous UTC from 20 May 2027, |UT1-UTC| up to 3,600 seconds
• CGPM 2026, draft resolutions — Draft C, which became Resolution 5
• Fortius Intel, "Sixty-Eight Nations Vote in October on What a Second Means" — analysis of the vote's consequences for financial systems subject to RTS 25
• Internal — Stratum 0 → 16 propagation: technical context of the NTP hierarchy