Leap second removal by 2027 prompts NTP, PTP and database reconfiguration work

A deadline for linear time

Two guides published on dev.to, both dated 15 October and carrying the same byline, set out how infrastructure teams should prepare for the disappearance of the leap second. According to the first guide, a resolution by the International Bureau of Weights and Measures (BIPM) was passed in 2025 and becomes mandatory on 1 January 2027. The second guide describes the change as already in force from 2025. That disagreement about the timeline is one of several details the posts do not reconcile, and it is reason enough to verify the deadline against the BIPM's own publications before scheduling work.

What leap seconds are, and why they are going away

A leap second is an extra second occasionally inserted at the end of 30 June or 31 December to keep UTC, the civil clock, aligned with UT1, the rotation of the Earth. The guides note that 27 have been added since 1972. Each insertion creates a minute with 61 seconds and a timestamp of 23:59:60, which many parsers, databases and logging systems were never built to handle.

The dev.to posts argue the mechanism has outlived its usefulness. Special-case logic for the extra second widens the error surface in NTP and PTP implementations, and the second guide recalls servers freezing while processing leap seconds in 2012 and 2015, disrupting banking and telecom services. Once insertions stop, UTC behaves as a linear clock. The posts put the fixed offset between UTC and TAI at 37 seconds and expect roughly 0.9 seconds of divergence to accumulate each year, though they describe what is drifting away from what in slightly different terms.

The operational risks the guides highlight

• A surprise 61-second minute in a legacy NTP stack can corrupt databases, logs and distributed ledgers, the first guide warns.
• Repeated or negative timestamps can break data pipelines, trade ordering and telecom sessions, according to the second.
• Compliance regimes including EU MiFID II, SEC Rule 17a-4 and ESMA are said to demand timestamp accuracy around one microsecond, leaving little headroom for clock anomalies.
• Billions of low-power IoT devices run minimal NTP clients that cannot cope with a 61-second minute.

What the migration involves

Both posts walk through roughly the same sequence. Inventory every time service on the estate, including NTP, PTP, SNTP and chrony. Upgrade daemons, with the first guide suggesting chrony 4.2 or later and ntpd 4.2.8p15 or later. Point leap-second tables at /dev/null so no insertion can occur, and confirm afterwards that the leap indicator reads zero. Databases should store timestamps as raw epoch values with no leap adjustment, and Java applications can rely on Instant.now(), which the second guide calls already linear.

The two posts diverge on offsets. The first configures a static UTC-TAI offset of 37 seconds in chrony and an offsetFromUTC value of 37 in PTP, refreshed yearly by script. The second instead runs ptp4l with a zero UTC offset and leap handling disabled. Both recommend sandbox testing before any production rollout, followed by monitoring: Prometheus alerts if the leap indicator ever becomes non-zero, and Wireshark captures filtered for leap flags in NTP and PTP traffic.

Claims worth treating with caution

Several specifics in the posts rest on no cited evidence: a reported 350 percent spike in searches for leap-second removal, more than 2,000 Reddit comments on migration strategies, and the assertion that NYSE, CME and Binance are already testing offset-model patches. These read as colour about community attention rather than verified reporting. The date conflict between the two guides, and their divergent PTP configuration advice, suggest treating them as starting points rather than authoritative runbooks.

Why it matters

Time synchronisation is a hidden dependency of almost every distributed system, from database consistency to trading-order sequencing to cloud billing. Removing leap seconds eliminates one well-documented class of failure, but it replaces an occasional, announced event with a continuous offset that every time-sensitive system must account for. Auditing assumptions about 61-second minutes, parser behaviour and offset handling is cheap now and expensive during an incident, and if the 2027 deadline holds, teams that wait will be doing that audit under pressure.