What happens during a UTC smear second

A leap second is scheduled for 23:59:60 UTC. On a server running Google's smear, the clock never jumps to that impossible timestamp. Instead, for 24 hours centred on that moment, each tick lasts roughly 11.6 microseconds longer than a true atomic tick.

At 12:00:00 UTC on the day of the leap second, the smeared clock reads 12:00:00 exactly. By 18:00:00 UTC it lags true UTC by about a quarter of a second. By midnight the gap reaches half a second. Then the smear unwinds: at 06:00:00 UTC the following day the clock is a quarter-second behind, and by 12:00:00 UTC it has caught up. The extra second was never inserted as a discrete event. Applications see a normal-length day, each tick very slightly longer than usual.

A leap smear replaces one abrupt second with a slow drift over many hours. The maximum deviation from true UTC is half the smear window's worth of accumulated delay. For a 24-hour smear, that ceiling is half a second. The clock never shows 23:59:60.

Why a smear exists: the problem with sudden leap seconds

A leap second causes three concrete failures.

Duplicate timestamps. A database row written at 23:59:59.9 and another written at 23:59:60.1 can share the same Unix timestamp. Unix time counts ticks since 1970-01-01 and deliberately skips leap seconds: the same integer covers both 23:59:59 and 23:59:60. Systems that rely on timestamps for ordering or uniqueness break.

Application crashes. Software written without leap-second handling receives a time string containing ":60" for the seconds field. Many parsers reject this as invalid. The 2012 leap second caused outages at Reddit, Mozilla, and LinkedIn because their Java and Linux stacks did not expect the value.

Cluster desynchronisation. In a distributed system, different nodes may see the leap second at slightly different moments, or one node may freeze during the insertion while another does not. This causes heartbeat failures, split-brain scenarios, and dropped transactions.

Google's 2008 solution: do not insert the second at all. Make the clock slow enough that the extra second is absorbed without any discontinuity.

How a UTC smear works under the hood

Google's approach, first deployed in 2008 and refined since, operates at the NTP (Network Time Protocol) layer. A Google NTP server does not serve true UTC during the smear window. Instead it serves a deliberately slowed version of UTC.

The smear window is 24 hours, centred on the leap second. At the start of the window the clock matches UTC exactly. Over the next 12 hours the server gradually falls behind, reaching a maximum of half a second behind UTC at the midpoint (the moment the leap second would have been inserted). Over the following 12 hours it catches back up. The rate of slowdown is constant.

Amazon Web Services uses a similar technique but with a different window length and centring. AWS's smear runs for 20 hours, starting 10 hours before the leap second and ending 10 hours after. The maximum offset is still about half a second.

What a UTC smear breaks

The smear solves one set of problems and creates another. During the smear window, the smeared clock disagrees with true UTC by up to half a second. This causes issues when:

  • Two cloud providers compare timestamps. If one smears and another does not, or they smear over different windows, their clocks diverge. A log event from AWS might appear to occur before a causally prior event from a non-smeared system.
  • An application reads time from a smeared NTP server and also from a GPS receiver. GPS time does not include leap seconds and is not smeared. The two sources disagree.
  • A financial trade timestamped during the smear window is audited later. The smeared timestamp differs from the true UTC time by hundreds of milliseconds. Enough to matter for high-frequency trading audits.

Google's documentation is explicit about this trade-off: applications that compare timestamps across providers should use a monotonic clock for ordering and consult true UTC only after the smear window ends. Systems that need sub-second accuracy during a leap second should not rely on a smeared NTP source.

Will the 2035 leap second abolition end UTC smears?

In 2022, the General Conference on Weights and Measures (CGPM) adopted Resolution 4: leap seconds will be abolished by 2035 at the latest. After that date, UTC will no longer insert or remove seconds to stay within 0.9 seconds of astronomical time. The difference between UTC and UT1 will be allowed to grow beyond one minute.

The tech industry welcomed the decision. A smear is a workaround for a problem that should not exist. Once leap seconds stop, smears become unnecessary. Google and Amazon have both stated publicly that they will revert to serving true UTC continuously after the abolition takes effect.

For now, smears remain the standard practice among the largest cloud providers. If you run a server farm, you can choose to smear, to freeze the clock for one second (the traditional Linux approach), or to step the clock forward and risk the consequences. The smear is the most reliable option for services that cannot tolerate a discontinuity.

The abolition date of 2035 is a target, not a guarantee. If the replacement mechanism (likely a larger permitted offset between UTC and UT1) is not finalised, the deadline could slip. But the direction is clear. Leap seconds, and the smears that hide them, are a temporary feature of timekeeping, not a permanent one.