What Happens to Computers During a Leap Second

A leap second is a one-second adjustment occasionally added to Coordinated Universal Time to keep it aligned with the Earth's actual rotation, which is very slightly irregular and doesn't match the perfectly steady tick of an atomic clock. Without leap seconds, clock time and solar time would very slowly drift apart over centuries. With them, computers occasionally have to represent a minute with 61 seconds in it — something almost no software is written to expect.

The moment itself

When a leap second is added, the clock sequence at midnight UTC reads ...23:59:59, 23:59:60, 00:00:00 — that extra "23:59:60" is the leap second itself, a valid moment in time that most timestamp systems have no way to represent, because they were built assuming every minute has exactly 60 seconds.

Real incidents, not hypotheticals

The 2012 leap second caused problems at several major sites, including outages linked to Linux kernel handling of the extra second interacting badly with certain scheduling code. Several other well-known outages around subsequent leap seconds have been traced to similar root causes — software that assumed time moves forward in strictly regular one-second increments, encountering a second that doesn't fit that assumption.

How modern systems cope with it

A common technique, used by several major cloud providers, is called a "leap smear" — instead of inserting one very unusual extra second, the clock is slowed down by a tiny, imperceptible amount over many hours before and after the leap second, so that by the time UTC would have needed the extra second, the smeared clock has already quietly absorbed it. It's a workaround, not a fix, but it avoids the single sharp discontinuity that breaks the most software.

The bigger picture

International bodies have been moving toward abolishing leap seconds entirely, precisely because they cause more operational risk than the astronomical benefit is worth for most systems. Until that fully takes effect, the safest approach for anyone writing time-sensitive code is the same advice that applies everywhere else in this space: don't assume a fixed, guaranteed relationship between wall-clock time and elapsed real time, and use a monotonic clock source for anything measuring a duration rather than a wall-clock timestamp.