Leap Seconds and GPS Time: Why Two Clocks Disagree

The problem: days are not exactly 86,400 seconds

Earth's rotation is not a metronome. It slows down irregularly under tidal friction, so the length of a mean solar day drifts slightly from the 86,400 seconds that atomic clocks count. Since 1972 the international timekeeping community has reconciled the two by inserting leap seconds — extra seconds added to UTC so that civil time never drifts more than 0.9 seconds from astronomical time. Twenty-seven leap seconds have been inserted since then; the most recent was at the end of 2016, when the clocks jumped from 23:59:59 on December 31 to 23:59:60, then to 00:00:00 on January 1, 2017.

Three clocks, three policies

The same physical moment is measured by different systems that made different decisions about leap seconds:

UTC (Coordinated Universal Time) applies leap seconds. A UTC day is usually 86,400 seconds but occasionally 86,401.
GPS time ignores them. The GPS clock has run continuously since its epoch — midnight UTC on January 6, 1980 — with no leap adjustments. Because every leap second since 1980 has been positive, GPS time now runs 18 seconds ahead of UTC.
Unix time also ignores them, by definition: POSIX requires every day to have exactly 86,400 seconds. So Unix timestamps are a clean linear counter, and the UTC clock they render may actually be a second (or more) away from the true astronomical instant at the moment a leap second occurs.

This is not a bug in any of the three systems — it is three different answers to the same design question: should civil time follow the Earth, or follow the atoms?

Converting between GPS and Unix time

GPS receivers report time as a week number plus seconds-of-week since the GPS epoch (1980-01-06 00:00:00 UTC). To convert a GPS reading to Unix time:

Total GPS seconds = week × 604800 + seconds_of_week.
The GPS epoch in Unix terms is 315964800 seconds after the Unix epoch (January 6, 1980).
Subtract the current leap-second offset (18): unix = gps_total_seconds + 315964800 − 18.

For example, GPS week 2434, second 0 is 2434 × 604800 = 1,472,083,200 GPS seconds; adding the 315,964,800 epoch offset and subtracting 18 gives a Unix time of 1,788,047,982, which is a moment in August 2026. The GPS time converter does this arithmetic in both directions and exposes the 18-second offset as an editable field — the instant the next leap second is announced (via IERS Bulletin C), the offset becomes 19 and the value should be updated.

Why GPS keeps its own clock

GPS navigation depends on precisely synchronized clocks in the satellites. A leap second inserted into the broadcast time would require coordinating a jump across the entire constellation — an operational risk for zero navigation benefit — so the GPS system simply does not do it. Receivers convert to UTC locally by applying the current published offset, which is why consumer devices know both "GPS time" and "UTC" at the same moment.

Practical consequences for developers

Do not assume a second is a second. If your system needs to agree with a GPS receiver or an observatory within one second, you must track the leap-second offset. If you are building ordinary web software, Unix time is fine — the civil-time error only exists for the one second of an actual leap event.
Timestamps can repeat or skip. During an inserted leap second, a UTC wall clock reads 23:59:60 — a value that does not exist as a Unix timestamp. Logs written with naive local time can end up with duplicate or missing seconds around the transition.
The offset is not constant. The 18-second gap between GPS and UTC grows whenever a new leap second is inserted. Code that hard-codes "18" will silently produce wrong conversions after the next announcement.
Satellite week numbers roll over. GPS week numbers are broadcast in 10 bits, so the counter resets every 1,024 weeks (about 19.6 years) — most recently in April 2019. Old receivers that did not handle the rollover briefly reported dates in 1999.