Guide

Unix timestamps and leap seconds: what the counter really measures

Understand why Unix time does not count leap seconds as separate instants and how that affects conversions and durations.

by Tools in a Tab · Published on · Reviewed on

Short answer

The POSIX model of seconds since the epoch treats every day as though it had exactly 86,400 seconds and omits leap seconds from its formula. A conventional Unix timestamp therefore cannot uniquely identify the UTC label 23:59:60; systems must resolve the adjustment through their own clock policy.

What a leap second is

UTC can insert an additional second to keep civil time close to Earth’s rotation. When this occurs, its labels can include this sequence:

23:59:59
23:59:60
00:00:00

The 23:59:60 label belongs to UTC. It does not mean every computer clock exposes an additional Unix number with one universal mapping.

What the Unix and POSIX model does

The POSIX formula calculates days, hours, minutes, and seconds from 1970-01-01 00:00:00 UTC as though all days had the same length. Leap seconds are ignored so arithmetic over the nominal counter remains simple.

Consequently, mapping between a UTC label during a leap second and a timestamp is not one to one. A system may repeat a value, pause briefly, or spread the adjustment across an interval. Those operating policies are not encoded in the Unix number itself.

Example around an ordinary day

Without a leap second, consecutive UTC midnights differ by:

24 × 60 × 60 = 86400 seconds

The Unix timestamp converter accepts second fields from 00 to 59, matching ECMAScript Date. It does not accept 23:59:60 or claim to reproduce the clock policy of a particular time server.

Step clocks and leap smear

Some systems apply an adjustment in one step. Others use a leap smear and slightly change the clock rate over a window. Providers can choose different windows, so comparing wall-clock values from different sources near an event requires knowing each source’s policy.

A stored timestamp without that context cannot later reveal which adjustment strategy produced it.

Civil time versus elapsed duration

For high-precision intervals, telemetry, or distributed coordination, keep these concerns separate:

  • the UTC civil time displayed to a person;
  • the monotonic clock used to measure duration;
  • the time scale and synchronization source;
  • the leap-second policy applied by that source.

A system clock can be corrected forward or backward. Measuring an operation by subtracting civil dates does not provide the guarantees of a monotonic clock.

Frequent mistakes

  • Claiming Unix time counts every physical second since 1970.
  • Passing :60 to an API whose valid seconds are only 00 through 59.
  • Mixing timestamps from providers with different smear policies.
  • Using the wall clock for critical elapsed-duration measurements.
  • Assuming 86,400 describes every historical UTC day as an astronomical scale.

The POSIX rationale for seconds since the epoch states that leap seconds are ignored in this model. RFC 3339 permits the second label 60 for a UTC leap second. These are separate layers: one civil representation and one practical counter used by systems.