End of the Leap Second: What Changes for Your NTP Servers by May 2027

By Richard DEMONGEOT | Published 16 October 2026 | Reading time: 9 min

The leap second is coming to an end. The last one will remain that of 31 December 2016: IERS Bulletin C 72 (6 July 2026) announces "NO leap second […] at the end of December 2026", and recalls that a leap second is only introduced "at the end of the months of December or June". The next such date, 30 June 2027, falls after the effective date. TAI − UTC therefore stays at 37 seconds.

For the history of the mechanism, the outages it caused and the details of the vote, see our leap second page. This article answers a different question: what should the administrator of an NTP server check by May 2027? What we say about chrony and ntpd comes from their documentation and their current source code. As of 16 October 2026, neither project has announced what it will do with its leap second code, and we do not guess.

1. What the resolution says, and what it does not

Resolution 5, "On the technical actions needed to ensure the continuity of UTC", comes down to two decisions: continuous UTC from 20 May 2027, and a |UT1-UTC| difference raised to 3,600 seconds, "ensuring the long term continuity for UTC for several centuries". It welcomes the commitment of the IERS "to take all necessary measures to change its operational provision for, and its announcement of, leap seconds".

It says nothing about NTP, the leap-seconds.list file or software. Among its grounds, one passage speaks directly to time operators: "the use of different mitigation methods for leap second introductions by global service providers in their server systems, in order to avoid time steps, leads to inconsistency in timing between different systems". That is smearing, practised notably by Google and AWS, which our leap second page covers in detail.

2. What remains: the Leap Indicator

The two Leap Indicator bits stay in every NTP packet: the resolution does not touch the protocol, defined by RFC 5905 (§7.3).

ValueMeaningAfter 20 May 2027
00No warningThe normal value, permanently
01Last minute of the month has 61 secondsTo be treated as an anomaly: no leap second can be announced any more
10Last minute of the month has 59 secondsNever used; likewise to be treated as an anomaly
11Clock unsynchronizedUnchanged: the alarm keeps its use

"Of the month" follows the field's definition (RFC 5905, §7.3) and RFC 8633 (§3.7), under which the second is only applied on the last day of a month; Figure 9 of RFC 5905 says "last minute of the day" (details).

This matters because the local list is not a barrier on its own. The chrony documentation says so: if a majority of time sources announce a leap second on the last day of June or December, "it will be accepted even if it is not included in the timezone". On the ntpd side, the code (ntp_proto.c and ntp_leapsec.c) accepts an announcement carried by more than half of its surviving sources, but only if its local table has expired. Two habits follow: keep sources that follow the IERS list, and monitor the leap status. 

# chrony: the expected status is "Normal"
chronyc tracking | grep 'Leap status'
Leap status     : Normal

# ntpd or NTPsec: leap=00
ntpq -c 'rv 0 leap'

3. leap-seconds.list: the 28 June 2027 expiry

The leap-seconds.list file, maintained by the IERS and redistributed by the IANA tz database (the tzdata package), carries an expiry date on its #@ line, in seconds since 1900. The current version expires on 28 June 2027, five weeks after continuous UTC takes effect. To read it on a server: 

date -u -d @$(( $(awk '/^#@/{print $2}' /usr/share/zoneinfo/leap-seconds.list) - 2208988800 )) +%F
2027-06-28

What the software does with an expired list, according to its current code:

  • chrony (leapdb.c): once the expiry has passed, it logs "Leap second list … needs update" and keeps using the file's content. The last entry, TAI − UTC = 37 s from 1 January 2017, remains correct.
  • ntpd (ntp_util.c) and NTPsec (ntp_util.c): one warning a day during the 28 days before the expiry ("will expire in less than N days"), then one error a day afterwards ("expired N days ago"). With an expired table, ntpd again accepts a majority announcement from its sources (section 2).

What happens next depends on the IERS. On 15 October 2026, the tz database coordinator, Paul Eggert, wrote to the director of the IERS centre that maintains the file; he expects the expiry to be dropped or moved far into the future. As of 16 October, no new version has been published.

4. chrony's leapsectz: check that it reads something

chrony knows two local sources. leapsectz right/UTC queries a tz time zone that contains the leap seconds; leapseclist, added in chrony 4.6 (NEWS), reads leap-seconds.list directly. On Debian 13, right/UTC is absent by default (as we found on our servers): the right/ zones moved to the tzdata-legacy package, not installed by default (tzdata changelog, version 2023c-7), and the chrony.conf shipped by Debian already uses leapseclist on leap-seconds.list (chrony changelog, version 4.6~pre1-1). An older or separately managed configuration that keeps leapsectz right/UTC then reads nothing, and chrony discards it at startup with "Timezone right/UTC failed leap second check, ignoring".

The documentation gives the test, to run on every server that keeps leapsectz: 

TZ=right/UTC date -d 'Dec 31 2008 23:59:60'
Wed Dec 31 23:59:60 UTC 2008     # the time zone contains leap seconds

# otherwise, replace with (chrony 4.6 or later):
leapseclist /usr/share/zoneinfo/leap-seconds.list

A local source stays useful after May 2027. According to the documentation, it also matters when the system clock must carry the correct TAI − UTC offset (the kernel only gets it with leapsecmode system), which counts for applications reading CLOCK_TAI. And it is what lets a server recognise an erroneous announcement (section 2). Our own configuration is described in the policy of our servers.

5. Is smearing still useful?

Smearing only applies around a leap second. Google says so of its service: "Before and after this period, smeared clocks and time service agree with clocks" that follow UTC (Google Public NTP, Leap Smear). With no leap second after 20 May 2027, there is no smear period left.

  • Smearing sources (time.google.com, Amazon Time Sync): the risk of mixing them with compliant sources only existed during the window. Nothing to remove; the leap second page covers this point.
  • chrony: smoothtime … leaponly only smooths leap seconds and will have nothing left to smooth. Without leaponly, the directive keeps a separate documented use: softening large corrections of the server's clock for its clients, for example after a long outage.
  • ntpd: leapsmearinterval remains an experimental option, only present if ntpd was built with --enable-leap-smear (ntpd documentation).

6. What the administrator should check

  1. The local source exists. The leapseclist (chrony) or leapfile (ntpd) directive points to a file that is present, and chrony logs "Using leap second list …" at startup; ntpd, "leapsecond file (…): loaded, expire=…".
  2. No orphaned leapsectz. The TZ=right/UTC test from section 4 answers 23:59:60, or the directive is replaced.
  3. The tzdata update is planned before 28 June 2027, with an alert on "needs update" (chrony) and on "will expire in less than" (ntpd, NTPsec) in the logs.
  4. The leap status is monitored. Leap status : Normal or leap=00; after 20 May 2027, any value other than 00 or 11 should be handled as a source incident, since no leap second can be announced any more.
  5. Applications have nothing to change for the current time: Unix time has never counted leap seconds. To convert old timestamps, the table is still needed; the timestamp converter gives the TAI − UTC offset in force on a given date.

7. Timeline

DateEventSource
31 December 201627th and last leap second; TAI − UTC = 37 sIERS
6 July 2026Bulletin C 72: no leap second at the end of December 2026IERS
15 October 2026Resolution 5 adopted by the 28th CGPMBIPM
20 May 2027Continuous UTC takes effectBIPM
28 June 2027Current version of leap-seconds.list expiresIANA

Sources

Frequently asked questions

Do I need to change my NTP configuration before May 2027?

Not because of the resolution itself: it does not touch the NTP protocol. You should however check three things: that chrony or ntpd reads a leap second list that exists (leapseclist or leapfile), that the old leapsectz right/UTC does not point to a missing time zone, as on Debian 13, and that tzdata will be updated before 28 June 2027, the expiry date of the current list.

What happens when leap-seconds.list expires on 28 June 2027?

In their current code, chrony logs 'Leap second list … needs update' and keeps using the file's content; ntpd and NTPsec warn once a day during the 28 days before the expiry, then log an error once a day afterwards. On 15 October 2026, the tz database coordinator asked the IERS to drop or push back the expiry date; as of 16 October, no new version has been published.

Is leap smearing still useful once leap seconds end?

Leap smearing only acts during a leap second window: Google states that outside that window its smeared clocks agree with UTC. With no leap seconds after 20 May 2027, there is no window left. chrony's smoothtime directive without the leaponly option keeps a different, documented use: smoothing large clock corrections on the server.

Does the Leap Indicator disappear from the NTP protocol?

No. CGPM Resolution 5 does not change the protocol: the two Leap Indicator bits remain defined by RFC 5905. Value 11, clock unsynchronized, keeps its use. Values 01 and 10 announce a second to add or remove; after 20 May 2027, they should be treated as an anomaly, since no leap second can be announced any more.