UNIX time (UNIX timestamp) is often described as "the number of seconds elapsed since 1970-01-01T00:00:00Z," but that is not strictly accurate. In reality, it ignores "leap seconds," which compensate for irregularities in Earth's rotation speed. Without understanding this mechanism, you can run into unexpected discrepancies when computing log timestamps or synchronizing time across systems.

Earth's rotation speed is slightly irregular, so a small gap gradually builds up between time based on the precise accumulation of atomic-clock seconds (TAI, the basis of UTC) and time based on Earth's actual rotation. A "leap second" is a single second inserted (or, rarely, removed) by decision of international bodies to keep this gap within 0.9 seconds. Since its introduction in 1972, 27 leap seconds had been inserted as of 2025, each one added at the very end of June 30 or December 31 by temporarily creating the otherwise nonexistent time "23:59:60."

The POSIX standard defines UNIX time as ignoring leap seconds and always counting a day as exactly 86400 seconds. This means that even on a day when a leap second is inserted, the UNIX time counter still only advances by 86400 seconds. Even though that day actually has 86401 seconds in UTC, UNIX time treats that extra second as if it never existed — that is the essence of this mechanism. As a result, at the instant a leap second is inserted, the mapping between UNIX time and UTC briefly rewinds, meaning the same UNIX timestamp value appears twice.

• If you compute "elapsed seconds" across a span that includes a leap second by simply subtracting UNIX timestamps, the result comes out one second shorter than the actual elapsed time. This one-second discrepancy can matter for financial systems requiring millisecond precision or for ordering guarantees in distributed systems.
• Large operators such as Google and Amazon avoid this problem with a technique called "leap smearing": instead of jumping the clock at the instant of the leap second, they gradually slow down (or speed up) server clocks over several hours to a full day around the event. Understanding this premise also helps when running your own NTP synchronization, making unexpected time jumps easier to spot.
• At a 2022 international conference, a resolution was passed to abolish leap seconds by 2035. After abolition, proposals under discussion would let the gap between UTC and UT1 (astronomical time) accumulate before correcting it in larger steps, such as a full minute at a time. The premise of a fixed 86400-second day for UNIX time is expected to remain unchanged either way.

For ordinary calendar-to-timestamp conversions, you rarely need to think about leap seconds — most libraries and operating systems follow the POSIX definition that ignores them, so the results match everyday expectations. The case to watch for is computing the exact elapsed real time between two instants: if the interval spans a leap second, a simple difference of UNIX timestamps can be off by up to the number of leap seconds inserted during that span.