Why leap seconds are on borrowed time
Since 1972, the International Earth Rotation and Reference Systems Service (IERS) has periodically inserted leap seconds into Coordinated Universal Time (UTC) to keep it roughly aligned with observed solar time (UT1). The Earth’s rotation is not constant, and those corrections were meant to keep civil time from drifting away from astronomical observations. For scientists and astronomers who still synchronize legacy equipment to UTC, that alignment has value. But in the five decades since the first leap second, UTC has been adjusted 27 times — and the mechanism has become a liability for modern systems that depend on continuous, monotonic time.
Meta is joining an industry-wide push to stop adding leap seconds entirely and hold UTC at the current offset of 27. The position is simple: leap seconds now create more risk and operational complexity than they solve, and new approaches are needed to replace them.
The physics behind the ticking clock
The Earth's rotation slows and speeds up due to a variety of factors, including the melting and refreezing of ice caps on the world's tallest mountains. A useful analogy is a spinning figure skater: as the skater spreads their arms, angular velocity decreases; tucking the arms back in increases it. The same principle applies to the planet's rotation, which is why UTC and UT1 drift apart over time.
So far, every leap second that has been inserted has been positive — the sequence runs 23:59:59 → 23:59:60 → 00:00:00. Such anomalies have caused crashes and data corruption in systems that assume a timestamp will never repeat or jump backward into a nonexistent second. But a negative leap second is also likely at some point, producing the sequence 23:59:58 → 00:00:00. A negative leap second has never been exercised at scale, and software that relies on timers or schedulers may not survive the test. Even the traditional positive leap second has been a recurring source of pain for anyone managing hardware infrastructure.
How timing professionals cope today
Many large operators, including Meta, use a technique called “smearing” to handle leap seconds. Instead of stepping the clock by a full second, they stretch or compress time over a longer window. Meta spreads the adjustment over 17 hours, starting at 00:00:00 UTC on the day of the leap event, based on the time zone data (tzdata) package. The duration and starting point are not standardized across the industry.
Meta picked 17 hours because hundreds of its Stratum 2 NTP servers perform smearing simultaneously. Each server must make only minimal steps during the smear; if the steps are too large, clients may deem some devices faulty and exclude them from quorum, risking an outage. Other companies smear over 24 hours starting at noon UTC the day before, or begin just two hours before the event. Algorithms vary too — kernel leap second correction, linear smearing with equal steps, cosine, and quadratic functions are all in use. Meta uses a quadratic model.
The leap indicator itself is not consistent across GNSS constellations such as GPS, GLONASS, Galileo, and BeiDou. Some broadcast the indicator hours ahead, while others propagate time in UTC with the leap already applied. Different constellations may disagree on the leap second value depending on the age of the satellites in the constellation. Nontrivial conversion logic is therefore required inside time sources, including Meta's own Time Appliance. Losing a GNSS signal at such a sensitive moment can mean missing the leap indicator entirely, resulting in a split-brain condition and an outage.
The leap event is distributed months in advance via the tzdata package and, for ntpd users, through a leap second file hosted by the Internet Engineering Task Force (IETF). An out-of-date copy of that file can cause an operator to miss a leap second entirely. Smearing is also fragile in practice: if an NTP server is restarted during the smear window, it may serve "old" or "new" time to clients and trigger an outage.
Public NTP pools generally avoid smearing, often passing the leap indicator to clients. Simple SNTP clients typically step the clock at the event; more capable clients may smear locally. Because big operators like Meta smear their public services, they are effectively unable to join the public NTP pools, which would mix constant-offset and smeared time sources. After the leap event, NTP software must keep applying an offset relative to its time source (GNSS, TAI, or atomic clock), and PTP software must propagate a UTC offset flag in announce messages — additional fragile machinery that must run indefinitely.
Real-world breakage
The most common source of leap second outages is code that assumes time moves only forward. A check with time.Now().Sub(start) returning a negative value can cause an application to misbehave while the system clock is stepped back. Such assumptions have led to many public incidents, and two are particularly instructive.
In 2012, Reddit went offline for 30 to 40 minutes after the leap second confused the high-resolution timer (hrtimer), triggering server CPU lockups. In 2017, Cloudflare's public DNS service was affected by a similar assumption that time cannot run backward. Upstream time values with negative input ended up passed to rand.Int63n(), causing Go to panic and the DNS server to crash. Go's use of a monotonic clock makes it less susceptible in most cases, but the problem persists in systems that don't have that protection.
A new approach for long-term timekeeping
Because leap seconds are rare, infrastructure teams have little practice dealing with them, yet these events repeatedly cause industry-wide disturbances. As demand for clock precision grows, the stability cost of leap seconds is no longer justified — and the current 27-second offset from UT1 should simply be kept for the foreseeable future.
