How Leap Seconds Affect UTC and Unix Time

#Leap seconds connect three different ideas of time

Atomic clocks are steady. Earth's rotation is not. Civil time tries to use both.

A leap second is a one-second adjustment to Coordinated Universal Time (UTC) designed to keep it close to UT1, the time scale derived from Earth's rotation. The adjustment is rare, announced in advance, and awkward for software because one UTC minute can contain a second labeled 23:59:60.

Time scale	What sets it	Continuous?	Application role
TAI	atomic clocks and SI seconds	yes	metrology reference
UT1	observed Earth rotation	no uniform tick rate	astronomical orientation
UTC	atomic rate plus integer-second adjustments	has included leap steps	civil time reference
POSIX time	nominal seconds since the Unix epoch	defined without leap seconds	operating systems and applications

As of August 2026, UTC is 37 seconds behind TAI, 27 positive leap seconds have been inserted, and none has been added since the end of 2016. IERS Bulletin C 72 confirms that there will be no leap second at the end of December 2026.

#Why UTC needs an occasional adjustment

Atomic physics defines the SI second. As the Earth exchanges angular momentum with the atmosphere, oceans, core, and other parts of the planet, its rotation changes. It also varies on longer timescales.

UTC ticks at the atomic rate, while leap seconds have kept |UT1 − UTC| within the established tolerance of 0.9 seconds. The IERS monitors the difference and every six months or so issues a Bulletin C announcing whether a step is needed or confirming that one is not needed.

This is the way a positive leap second at the end of a UTC day is marked:

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

The mechanism allows for a negative leap second, skipping a label, but there has never been a negative leap second.

#UTC, TAI, and UT1 answer different questions

The offsets are easier to interpret when each timescale has one job:

• TAI answers how continuous atomic time advances.
• UT1 answers how Earth is oriented in its rotation.
• UTC provides civil time at the atomic rate while remaining near UT1 under the current system.

When UTC's modern arrangement began in 1972, it already differed from TAI by 10 seconds. The 27 later positive leap seconds brought the difference to 37 seconds. It is therefore wrong to describe the current offset as “37 leap seconds since 1972.” It is a 10-second starting difference plus 27 inserted seconds.

#POSIX timestamps do not count every leap second

POSIX defines seconds since the epoch using nominal days of 86,400 seconds and a formula that deliberately ignores leap seconds. This gives a simple integer model for application code, but means that the difference of two POSIX timestamps is not necessarily the number of SI seconds elapsed during a leap insertion.

The standard definition does not require each clock service to provide the boundary the same way operationally. A variety of schemes have been used in real systems:

• repeat or step a clock value near the leap
• let the kernel apply a leap adjustment
• smear the adjustment over a longer window
• use a non-POSIX scale such as TAI for precision work

Never infer a provider's leap behavior from the word “NTP” alone. Document the time source and timescale.

#Leap smearing trades a step for temporary clock skew

A leap smear changes the clock rate slightly before and after a leap so applications never see 23:59:60 or a repeated second. The clock stays monotonic, but it temporarily disagrees with strict UTC.

Google's published recommendation is a linear 24-hour smear from noon to noon UTC. Amazon Time Sync Service distributes smeared time over NTP, but its PTP hardware clock follows UTC without smearing. Thus, disagreement within one system can arise from the mixing of sources during a leap event.

Strategy	Advantage	Cost
UTC step or repeat	follows the announced UTC event	can surprise timers and ordering code
24-hour smear	avoids an abrupt wall-clock step	temporarily differs from strict UTC
TAI clock	continuous SI-second timeline	requires explicit conversion for UTC display

There is no single smear standard all providers use. They may differ if the windows or functions of two smeared clocks are different.

#Where applications get hurt

It is not the extra label that usually causes the leap-second failures, but an unstated assumption.

• A parser rejects :60 even though the upstream feed can emit it.
• A duration calculation assumes wall-clock timestamps form a strictly increasing sequence.
• Two hosts use different smear policies and produce timestamps that cannot be compared at subsecond precision.
• A database accepts ordinary RFC 3339 seconds but rejects a leap-second string.
• An application mixes POSIX, UTC, TAI, GPS, or smeared time without recording the scale.
• Monitoring treats a repeated, skipped, or slowed clock reading as corrupt data.

The simplest answer for normal business software is usually to just use one well-managed time service, rather than to generate leap-second strings. Systems needing a traceable physical elapsed time should use a defined continuous scale. The conversion metadata needs to be maintained.

#Test the boundary without waiting for the next announcement

Use recorded or simulated inputs. Do not move a shared production clock.

2016-12-31T23:59:59Z
2016-12-31T23:59:60Z
2017-01-01T00:00:00Z

Test at least these behaviors:

1. Does the parser accept, reject, or normalize a :60 second?
2. Does ordering remain stable if a clock repeats or smears?
3. Can the data model record the timescale and smear policy?
4. Do all hosts use compatible time sources?
5. Does elapsed-time measurement use a monotonic clock rather than wall time?
6. Can the system handle a negative leap event, even though none has occurred?

Rejecting leap notation can be a valid contract. Failing unpredictably is not.

#The plan for continuous UTC is still being finalized

The 27th General Conference on Weights and Measures adopted Resolution 4 in 2022. It calls for increasing the maximum permitted |UT1 − UTC| in or before 2035, which would make leap adjustments far less frequent and allow UTC to operate continuously for a long period.

The resolution itself did not declare, forever, a fixed TAI-UTC offset, nor did it specify all the implementation details. A draft prepared for the 28th CGPM in 2026 proposes making continuous UTC effective on May 20, 2027 and increasing the limit to one hour. Because that text is a draft at the time of this article’s update, implementations should follow the adopted BIPM and IERS decisions, rather than code the proposed date as settled policy.

Old data, protocols, test cases will still have leap second behavior even with policy changes. It would be trading one class of bug for another if we immediately removed all the code paths related to leap.

#Related reading

• What Is UTC Time?
• Daylight Saving Time Explained
• ISO 8601 and RFC 3339
• NTP Timestamp Converter
• GPS Time Converter
• Unix Timestamp Formats