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
:60to an API whose valid seconds are only00through59. - 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.