NTP Leap Second: Leap Indicator, Smear vs Step & Operator Retrospective

The leap second is one of the subtlest and most-dreaded mechanisms in the NTP protocol. Since 1972 it has compensated for the slow deceleration 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: 24 hours of advance warning, a switchover plan, and 48 hours of log scrutiny afterwards.

This page covers what every NTP operator or administrator needs to know: the origin of the mechanism, the 27-event history since 1972, how NTP signals the event, the two competing approaches (step and smear), chrony and ntpd behaviour, and the 2035 abolition voted in 2022.

1. Why the Earth forces us to add seconds

Since 1972, UTC (Coordinated Universal Time) has been defined as the count of SI seconds emitted by an ensemble of atomic clocks. UT1, on the other hand, is the time defined by the actual rotation of the Earth, measured by VLBI interferometry on distant quasars. The two drift apart because the Earth is slowing down: tidal friction, internal mass redistribution, core-mantle interactions. Over the long term, UT1 falls behind UTC by an average 1 to 2 ms per day — one second every 12 to 24 months on average.

The IERS (International Earth Rotation Service) tracks this drift and, when it approaches 0.9 seconds, publishes a "Bulletin C" announcing a leap second six months in advance. The event takes place either on 30 June or 31 December at 23:59:59 UTC: the 23:59:60 second is inserted (the rare 61-second minute), followed by 00:00:00 of the next day.

2. The 27 leap seconds since 1972

From 1972 through end of 2016, 27 leap seconds were added. All positive. The five most recent, also those experienced by the RDEM infrastructure:

Since 1 January 2017, the TAI − UTC difference has remained fixed at 37 seconds. No leap second has been added for eight years — a historic record caused by the unexpected acceleration of Earth's rotation.

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

The NTP protocol (RFC 5905) reserves the two most significant bits of the first packet byte for the Leap Indicator (LI) field. Four possible values:

When a Stratum 1 server receives the information (via its GPS/DCF77 refclock, or via the signed leap-seconds.list file from NIST), it starts propagating LI=01 in its responses 24 hours before the event. chrony and ntpd clients read this bit on each poll and schedule the local insertion.

4. Step vs smear: two schools

When 23:59:60 arrives, you must choose what happens on the system side:

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

Standard-compliant: the kernel inserts a true 61-second minute. This is the default for chrony and ntpd with leapsecmode=system/step on Linux. Benefit: the clock stays strictly aligned with UTC. Downside: two consecutive identical timestamps, and any application computing timespec.tv_sec - previous can obtain 0, breaking second-based timers.

4.2 The smear approach (spreading)

Popularised by Google in 2011: rather than a one-second jump, the clock is slowed by a few ppm over a 20–24 hour window around the event. Each tick lasts 1.000011574 s instead of exactly 1.0 s — the second is absorbed progressively. Benefit: no non-monotonic timestamp, no broken timer. Downside: during the smear window, the clock is up to 0.5 s off official UTC, which can be visible from a non-smeared external source.

4.3 Who does what in 2026

5. chrony: leapsecmode, smoothtime, leapsectz

chrony 4.x offers four modes, configured via leapsecmode in chrony.conf:

# /etc/chrony/chrony.conf

# Recommended mode for a production Stratum 2+ server:
# delegate leap insertion to the Linux kernel
leapsecmode system

# Alternative 1: 1-second step applied immediately
# leapsecmode step

# Alternative 2: progressive correction via slew (default rate 400 ppm)
# leapsecmode slew

# Alternative 3: smearing, with smoothtime
# leapsecmode ignore
# smoothtime 400 0.001 leaponly

# To test without waiting for the next event: local leap list file
leapsectz right/UTC
leapseclist /usr/share/zoneinfo/leap-seconds.list

The directive smoothtime 400 0.001 leaponly enables smearing limited to leap events. Maximum applied offset is 0.5 s, spread over ~1000 seconds, compatible with most jump-sensitive applications.

6. ntpd: leapfile, tinker step, kernel mode

ntpd (reference or ntpsec) reads the leap-seconds.list file maintained by NIST:

# /etc/ntp.conf

# Signed reference file, updated by IERS/NIST
leapfile /usr/share/zoneinfo/leap-seconds.list

# Default behaviour: compliant 1-second step
# Disable if needed with:
# tinker step 0

# To use Linux kernel mode on sync:
# enable kernel

The leap-seconds.list file must be updated regularly — it expires 6 months after issuance. Automate via cron:

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

7. What RDEM observed since 2005

• The day before: our Stratum 1 servers begin announcing LI=01 at 00:00:00 UTC (24 hours ahead). Time to avoid major deployments. Well-configured clients propagate the announcement downstream.
• The moment T: at 23:59:60 UTC, Stratum 1 inserts the second via its kernel. Downstream Stratum 2 applies it within the following seconds, with a measurable transient offset lasting 30 to 120 seconds.
• The next 24 h: logs show occasional false-positive "clock stepped" messages on poorly-synchronised clients. The most fragile applications we tracked historically were databases (rare but documented temporal-index corruption on pre-9.6 PostgreSQL and pre-5.6 MySQL) and second-cadence cron jobs.
• IoT clients: consistently the dirtiest. Many consumer devices ignore LI and resync abruptly afterwards — the visible one-second skip on a Wi-Fi clock on 1 January morning.
• Tooling: chronyc tracking and ntpq -c rv remain the only indispensable commands during the event. Keep a terminal open on them between 23:59:00 and 00:02:00 UTC.

The 2016-12-31 event stands out as the most recent and the one where consumer tooling (smartphones, internet routers) had best converged toward correct behaviour. The ecosystem is more mature than in 2005 or 2008, when we had to explain LI=01 in client logs.

8. Preparing for the next event

Even without an announcement on the horizon, maintaining the capacity to handle a leap second is part of NTP hygiene:

1. Verify the leap-seconds.list file on each server: head /usr/share/zoneinfo/leap-seconds.list must show a future expiration date.
2. Test leap mode on a staging server by manually injecting a leap file with a near date: logs must show correct anticipation.
3. Document the policy (step or smear) per infrastructure segment, and ensure a single client does not mix the two upstream.
4. Audit critical applications: any logic doing if (new_ts == old_ts) or assert ts_diff > 0 must be reviewed.
5. Schedule an observation window around the announced date if an event is triggered. The probability of a leap second before 2035 is low but non-zero.

9. The 2035 abolition: what to expect

In November 2022, the 27^th General Conference on Weights and Measures (CGPM) voted the resolution abolishing leap seconds by 2035. The text plans to:

• Maintain the current mechanism until 2035 at the latest.
• Widen the current UTC − UT1 tolerance (0.9 s) to a significantly larger value (not yet fixed — 100 s has been discussed, which would produce an adjustment event every 100–200 years).
• Give telecom, satellite navigation and finance operators time to migrate their chains.

For NTP, this changes nothing in the protocol — the Leap Indicator field stays in place for archives and legacy systems. Its activation simply becomes exceptional, then zero. chrony and ntpd implementations will continue to support the mechanism for several more decades for compatibility.

Resources and references

• IERS Bulletin C — official leap-second announcements
• leap-seconds.list (IANA) — up-to-date file
• RFC 8633 — NTP Best Current Practices, leap-second handling §3.2
• RFC 5905 — NTPv4, Leap Indicator field §7.3
• CGPM 2022 Resolution 4 — abolition decision
• Internal — Stratum 0 → 16 propagation: technical context of the NTP hierarchy