Leap Seconds and the Infrastructure That Breaks When the World Adds One

On rare occasions, the world's timekeepers do something radical: they insert an extra second into the global clock. It happens because the Earth's rotation is not uniform — the planet spins slightly slower than the atomic clocks that define the second, accumulating a discrepancy measured in milliseconds per day. Every few years that discrepancy grows large enough that a correction is required, and the world adds a leap second at the end of June or December.

One second. That's all it is. And it has caused more infrastructure failures, outages, and coordinated debugging catastrophes than almost any other single change the world schedules in advance.

The Problem With Adding a Second

The leap second is not a computer science concept. It's an astronomy concept that was imposed, somewhat optimistically, onto a computer science world. The systems of the modern internet were designed on the assumption that time flows monotonically forward at a constant rate. Unix time is defined as the number of seconds since an epoch — a count that assumes every minute has exactly sixty seconds and every day exactly 86,400 of them.

A leap second breaks that assumption. On the scheduled day, the final minute of the day has 61 seconds instead of 60. Timekeepers around the world must decide what their clocks do during that extra second, and every implementation choice has a failure mode.

The two options. A system can smear the leap second — spreading it out over the surrounding hours as a gradual clock adjustment so the extra second never appears as a discontinuity — or it can implement a genuine 61-second minute, inserting an actual second of wall-clock time that runs 23:59:60. Smearing hides the problem. Real leap seconds expose it. The systems that do real leap seconds are the ones that break.

A Short History of Second-Sized Failures

2012 — Reddit experiences a multi-hour outage during the leap second when a server whose clock went to 23:59:60 woke up thousands of sleeping threads at once, creating a cascading load spike.

2012 — Mozilla's infrastructure reports hiccups, and multiple JVM-based systems across the industry crash or misbehave as date-handling libraries fail to cope with second 60.

2015 — A major European router vendor reports network-wide instability during the leap second. Disks in some systems spin down, log daemons crash, and cloud control planes report timing anomalies.

2016 — A major DNS provider reports widespread resolver failures and the flight-reservation system of a major airline reportedly suffers a check-in outage linked to leap-second handling.

2017 — Linux distributions famously patch a bug in which a clock set to second 60 spins the CPU at 100% for an entire hour as a timer-callback loop goes rogue.

The pattern across every incident is the same: a small number of systems handling the leap second literally, a large number of downstream systems that assumed their upstream clock would never behave oddly, and a debugging process that took hours precisely because no one expects time itself to be the cause.

Why the Leap Second Is a Security Story

The leap second tends to be filed under reliability, but it belongs in a security context too. Its properties are the properties of a zero-day:

It's announced in advance. The international Earth rotation services announce leap seconds months ahead. An attacker who knows an organization's infrastructure better than the organization does has a predictable window in which a system is statistically likely to misbehave.
It's a distributed mutation. A leap second is a global state change delivered to every clock that trusts NTP or GNSS. Any code that assumes 60-second minutes is now executing against an input its authors never tested.
It masks itself. Post-incident logs during a leap second look like ordinary chaos — timeouts, retries, load spikes, resets. Unless the team knows to look at the calendar, the root cause is invisible.
It can be weaponized as a cover. An attacker conducting a real intrusion on the same day as a scheduled leap second gets to blame every anomaly — every modified timestamp, every jumped process, every crashed daemon — on a bug that everyone already expects.

Smearing, and the Differences It Makes

Because the leap second causes so much pain, large internet companies pioneered an alternative: smearing. Instead of implementing a genuine 61-second minute, a time server artificially slows its clock across the hours surrounding the leap second — typically a window spanning the surrounding midnight — distributing the extra second across roughly 86,400 individual adjustments of microseconds. To clients, the clock never jumps; it simply runs slightly slow for a day, the accumulated offset reaching exactly one second, then returning to normal.

Smearing solves the discontinuity problem for the systems that use the smearing server. It creates a new one: a smeared clock disagrees with an unsmeared clock by up to a full second for the duration of the window. Any organization that mixes smeared and unsmeared time sources — or whose vendors mix them — will see exactly the kind of mysterious, second-scale discrepancies the leap second was supposed to make impossible. Certificate validation, log correlation, and distributed locks that cross the boundary between the two regimes all become sources of plausible-looking errors.

The lesson is not that smearing is wrong. It is that a leap second is a global state change, and every global state change requires a single, coherent global response. Organizations that treat their time distribution as one unified system with a documented policy survive the event. Organizations that discover at 23:59:59 that two of their data centers implemented different policies do not.

The Silent Victims: Certificates and Schedules

Two categories of systems fail quietly rather than loudly during a leap second. The first is anything that computes durations or expirations from wall-clock time — TLS certificates, license files, scheduled jobs, token lifetimes. A system that computes "now plus one second" during the extra second can produce results that are subtly off, and if those results are written into audit logs or retention metadata, the corruption is permanent and nearly impossible to find.

The second is anything with a hard real-time schedule — industrial control systems, broadcast automation, financial market data pipelines. These systems often treat "the clock reached midnight" as an event to act on, and the extra second means the midnight event is followed by another second of the same minute. A scheduler that expected to move on at minute zero now finds itself re-running the final minute's work, or missing it entirely, depending on how it compares timestamps.

Leap Second, Meet Security Review

Organizations that treat leap seconds as a scheduled, adversarial event tend to survive them. Organizations that treat them as a Tuesday do not. The pragmatic playbook:

Stage	Action
Before	Confirm your time distribution (NTP/PTP) uses leap smearing or a proven leap-second strategy. Test date-handling libraries in a staging environment by simulating second 60. Inventory any system with a hard dependency on wall-clock time (licenses, certificates, audit logs, schedulers).
During	Stand up monitoring around clock jumps and time-sync errors specifically. Watch for unusual load, timer storms, and certificate validation failures. Keep a change freeze in place — a leap second is already the change.
After	Review logs for the window around the leap second. Correlate anomalies against the expected smearing window so you know what was benign. Document findings for the next occurrence.

The Political Context: Leap Seconds Are Being Phased Out

This is not a hypothetical problem to be fought forever. The leap second has a scheduled retirement. In 2022, the international community voted to eliminate leap seconds by or before 2035, replacing them with a system of so-called leap minutes — larger corrections applied much less frequently, perhaps once a century. The rationale is precisely the pain described above: the correction costs more, in aggregate infrastructure breakage, than it is worth to astronomy.

The transition creates its own security window. For the next decade, infrastructure will straddle two regimes: systems that still handle leap seconds and systems that have begun assuming they will never see one. Mismatched assumptions between the two — a downstream system that no longer expects second 60 receiving time from an upstream that still inserts it — will be the source of the next generation of subtle, time-related outages. This is the kind of discontinuity that rewards the paranoid.

Key Takeaways

A leap second violates the foundational assumption that every minute has sixty seconds — and software built on that assumption breaks in practice, not in theory.
Real incidents across Reddit, Mozilla, DNS providers, and airlines show the damage is concentrated in the literal implementers and cascades outward.
Leap seconds are a security story: predictable, distributed, self-masking, and a natural cover for concurrent malicious activity.
Leap smearing and pre-tested date libraries are the difference between a non-event and a fire drill.
The move to abandon leap seconds by 2035 will create a decade of mixed-assumption infrastructure — a fresh window for time-related failures.

It is a strange fact that the most carefully maintained clocks in human history can still take down a payment system because the Earth wobbles. The leap second is a reminder that timekeeping is not a solved problem — it is an interface between physics and software, maintained by committee, trusted by everyone, and tested by almost no one. Treat the next scheduled correction as what it is: the most predictable unannounced bug on the calendar.