Leap seconds meet nanosecond time sync
Data center time synchronization has moved well beyond the millisecond precision that NTP was designed to deliver. With PTP now able to align clocks to within nanoseconds, the traditional approach to handling leap seconds—smearing the correction over a longer window—becomes a greater liability than ever before.
Meta has previously argued for abolishing the leap second and has put that position into practice with its PTP deployments. The challenge is nontrivial: PTP's precision means that even the tiny time shifts introduced by smearing create unacceptably large deltas across a synchronized fleet.
Why NTP smearing gets a pass
Leap second smearing works by gradually adjusting clock speed so the one-second correction is spread over a longer period—for example, a day—rather than applied as a single jump. Meta's NTP infrastructure has historically relied on quadratic smearing at the Stratum 2 layer, which serves as the intermediate tier between time sources and downstream clients.
Quadratic smearing has been the preferred method because NTP clients dynamically adjust polling intervals as the pending correction grows, which naturally works better with a non-linear progression. The downside, however, is inconsistency: because clients communicate with servers at different times and rates, offsets may differ noticeably across a large fleet.
Linear smearing is more deterministic when the whole fleet pulls from the same time sources and smears in lockstep. Combined with the typical one-second synchronization cadence, that approach offers predictable correction that avoids the fleet-wide inconsistencies of quadratic methods.
An algorithmic approach for PTP
Nanosecond-level synchronization cannot tolerate even the modest deltas of linear smearing. A one-nanosecond step every 62.5 microseconds would still create measurable differences between servers over time—too much to support the guarantees PTP users expect.
Meta's answer is a "self-smearing" strategy implemented inside its fbclock library, the interface through which applications consume PTP time. The library returns a time interval—{earliest_ns, latest_ns}—representing the Window of Uncertainty (WOU). During a smearing period, each call adjusts those returned values according to the smearing algorithm, shifting time by one nanosecond every 62.5 microseconds.
This design has several operational advantages:
- The adjustment is stateless and reproducible—no coordination among servers is needed.
- Internal timekeeping remains in TAI, while UTC conversions happen only at the API boundary.
- Because the smearing start is anchored to
tzdatatimestamps, a server can recompute its position in the smearing window even after a reboot.
The tradeoffs are real, though. NTP deployments smear quadratically, while PTP systems smear linearly, so services that consume time from both ecosystems can see timestamp discrepancies of more than 100 microseconds during the smearing period.
The case for TAI and eliminating leap seconds
Even with a stateless, fixed-step smearing algorithm, the deltas between hosts remain significant at nanosecond scale. There's another subtle failure: services that run periodic jobs on precise intervals are still affected. After 60 seconds of smearing, scheduling can be off by close to one millisecond—enough to break guarantees on nanosecond-level accuracy.
That's why Meta recommends that customers use TAI rather than UTC whenever possible. TAI is unaffected by leap seconds entirely, eliminating the need for smearing logic. In practice, though, UTC conversion is still required in most cases, and the conversion has to happen somewhere in the time distribution chain.
Meta supports the international effort to discontinue leap seconds after 2035. Removing future leap seconds would let the industry standardize on UTC for high-precision timekeeping without the need for multiple smearing strategies across NTP and PTP ecosystems—simplifying infrastructure and letting time-sensitive systems reach higher precision with far less complexity.
