Leap seconds explained
Every few years a minute somewhere contains 61 seconds. A clock ticks 23:59:60 before rolling over to midnight. That extra tick is a leap second, and it exists to reconcile two different definitions of what a second is. For most developers the surprising part is that Unix time pretends leap seconds never happen, which is usually the right call and occasionally the source of a strange bug.
Two kinds of time
There are two clocks that disagree slightly.
- Atomic time measures seconds by counting oscillations of a caesium atom. It is extremely steady and has no idea what the Earth is doing.
- UT1 is astronomical time, defined by the actual rotation of the Earth. The planet's spin is irregular and, on average, slowly slowing down.
UTC, the time standard everyone uses, runs on atomic seconds but is kept within 0.9 seconds of UT1. When the gap grows too wide, the keepers of UTC insert a leap second so that noon stays roughly aligned with the Sun overhead. There have been 27 leap seconds since the practice began in 1972, all positive so far.
Why Unix time ignores them
A Unix timestamp is defined as the number of seconds since the epoch assuming every day has exactly 86,400 seconds. Leap seconds break that assumption, so Unix time simply does not count them. On a leap second, the Unix clock either repeats a value or holds steady for two wall clock seconds, depending on the implementation.
UTC: 23:59:59 23:59:60 00:00:00
Unix time: ...99 (repeat) ...00
The benefit is huge: any Unix timestamp converts to a calendar date with plain arithmetic, no table of historical leap seconds required. The cost is that Unix time is not a true count of elapsed physical seconds. Subtracting two timestamps that straddle a leap second gives an interval that is off by one second from reality. For almost all application code this does not matter. For satellite ranging, financial sequencing, or precise physics, it does.
Smearing the discontinuity
A clock that repeats or freezes a second is a problem for distributed systems that assume time only moves forward. The common fix is leap smearing: instead of one abrupt extra second, you spread it across a window, often the 24 hours around the event, making each second slightly longer. Google, Amazon, and others run smeared time on their infrastructure so that no clock ever shows 23:59:60 and no timestamp is ever repeated. The tradeoff is that a smeared clock disagrees with strict UTC by up to half a second during the window.
The plan to retire them
Leap seconds have caused enough outages and complexity that the global metrology community voted to stop. The resolution is to let the gap between UTC and UT1 grow much larger before any correction, with no new leap seconds through at least 2035, and to decide on a longer term scheme after that. In practice, the era of the 61 second minute is ending.
Day to day, treat timestamps as leap second free, because that is how Unix time already behaves. When you need to inspect a value, the timestamp converter runs locally in your browser, so the times you check never leave your device. Only reach for true elapsed physical time, which means a monotonic or atomic clock, when a one second slip across a rare event would actually harm your system. For the foundation, see Unix timestamp and epoch time explained.