Leap Seconds and Why Unix Time Ignores Them

The Earth does not rotate at a constant rate. Tidal friction is gradually slowing it, and shorter-term variation comes from atmospheric and core effects. Atomic clocks, by contrast, are extremely regular.

Left alone, the two would drift apart. A leap second is an extra second inserted into UTC to keep it within 0.9 seconds of the Earth’s actual rotational time. Twenty-seven have been added since 1972; none have ever been removed.

When one occurs, the UTC clock reads:

23:59:58
23:59:59
23:59:60      <- the leap second
00:00:00

That :60 is legal in UTC and legal in ISO 8601.

What Unix time does instead

Unix time is defined as elapsed seconds since the epoch assuming every day has exactly 86,400 seconds. There is no room in that definition for a 61-second minute.

So the counter repeats. The same Unix timestamp covers both the leap second and the second that follows it. Two distinct physical moments share one value.

Three consequences follow:

1. Unix time is not a true elapsed-seconds count. It is behind physical time by the number of leap seconds since 1970 — currently 27.
2. Timestamp subtraction can be short. A duration spanning a leap second is one second less than the real elapsed time.
3. Timestamps are not strictly unique. During a leap second, two events one second apart can carry the same timestamp, which breaks any ordering that relies on timestamp uniqueness.

Why this was the right trade

Representing leap seconds properly would mean every date calculation consulting a table of historical insertions — and that table cannot be extended into the future, because leap seconds are announced only about six months ahead. Any date arithmetic beyond that horizon would be provisional.

Unix time bought unconditional arithmetic simplicity for an error of 27 seconds accumulated over half a century. For almost all software that is an excellent trade.

When it is not an excellent trade

• Satellite navigation. GPS time deliberately does not include leap seconds and is now 18 seconds ahead of UTC. Mixing the two puts you 18 seconds — and a few kilometres — out.
• Financial trade sequencing. Regulations such as MiFID II mandate timestamp accuracy to 100 microseconds with demonstrable UTC traceability. A repeated second is a compliance problem.
• Distributed consensus. Systems that infer ordering from clocks need monotonic, unique timestamps.
• Anything measuring intervals. Use a monotonic clock, always — leap seconds are only one of several ways wall-clock time can move unexpectedly.

The 2012 outage

On 30 June 2012 a leap second took down a visible slice of the internet. A Linux kernel bug meant that when the clock was stepped backwards, hrtimer code entered a state where futex waits spun at full CPU. Reddit, Mozilla, Qantas’ booking system and others fell over simultaneously.

The lesson was not “leap seconds are dangerous” so much as “stepping a clock backwards is dangerous, and leap seconds are the one time it happens on a schedule”.

Smearing

The industry’s answer is to avoid the discontinuity entirely. Leap smearing spreads the extra second across a window — Google uses 24 hours centred on the leap second — by running clocks fractionally slow.

During a smear window:

• No clock ever steps backwards, and no minute has 61 seconds.
• Every timestamp is unique and monotonic.
• Your clock is up to 0.5 seconds away from true UTC for a day.

Google, Amazon, Meta and Microsoft all smear, but not identically. Google and Amazon use a 24-hour linear smear; others differ in window and shape. Machines synced to different smearing NTP pools disagree by up to a second during the window — so never mix smeared and unsmeared time sources in one cluster.

They are being abolished

In November 2022, the General Conference on Weights and Measures resolved to stop inserting leap seconds by 2035. UTC will be allowed to drift from solar time, with some much coarser correction — possibly a leap minute — deferred to the distant future.

The argument that won was straightforward: leap seconds cause real, recurring outages in computing infrastructure, and the astronomical alignment they preserve matters to almost no one who is not already applying their own corrections.

The last leap second was inserted at the end of 2016. Because the Earth’s rotation has recently sped up slightly, none has been needed since, and there is an outside possibility that a negative leap second — removing a second — could be required before 2035. No system has ever been tested against that.

What to do

For ordinary applications: nothing. Unix time’s simplification is the right default, and the converter treats every day as 86,400 seconds like everything else.

If you are in one of the exception categories:

• Use a monotonic clock for durations, never wall-clock subtraction.
• Know whether your NTP source smears, and keep the whole fleet consistent.
• Do not assume timestamps are unique or strictly increasing.
• If you need true elapsed physical time, use TAI, which has no leap seconds and is currently 37 seconds ahead of UTC.