Why is GPS time 18 seconds ahead of UTC?
GPS time and UTC matched at midnight, 6 January 1980. They diverged that same year. Every leap second added to UTC since then has widened the split: UTC pauses, GPS time marches on. As of September 2026, GPS time leads by 18 seconds. The offset is not a bug. It is a deliberate engineering choice made before the first Block I satellite reached orbit.
GPS time is a continuous atomic timescale. It never stops, never repeats a second, never inserts a leap second. UTC does all three. The Earth's rotation has slowed enough to require 27 leap seconds since 1972. Eighteen of those have been added since GPS time began. Each one pushed the two timescales further apart.
What happens if a GPS receiver ignores the offset?
The Global Positioning System needs unbroken time to compute a position. A leap second (a 23:59:60 inserted into UTC) shatters that continuity. If a GPS receiver stopped to account for one, your position could drift by hundreds of metres. The US Naval Observatory decided in 1980 that the system would never add leap seconds.
The offset between GPS time and UTC is broadcast in the GPS navigation message. Every receiver reads it and applies it automatically to show you UTC. Your phone stays correct even though the satellites run 18 seconds fast.
Here is the catch. If a receiver fails to apply that offset (firmware bug, expired almanac, misconfigured survey-grade unit) the position error is not small. A single second of timing error translates to roughly 300 kilometres of position error, the distance light travels in that time. An 18-second error moves your reported location by a continent.
When do you need to manage the UTC vs GPS time offset yourself?
Consumer devices handle this silently. Your car GPS, your phone, your fitness watch: all read the broadcast offset and convert GPS time to UTC without you noticing.
The people who must track the gap manually:
Surveyors and geodesists. Raw GPS observation data (RINEX files) records timestamps in GPS time, not UTC. Process a RINEX file assuming the timestamps are UTC and your survey coordinates will be wrong. Apply the current GPS-UTC offset before you start.
Timing and synchronisation engineers. Precision time distribution systems often use GPS receivers as a UTC source. The receiver outputs UTC by subtracting the broadcast offset. Old firmware that mishandles a new leap second can leave the output wrong by a full second until a patch arrives.
Anyone working with raw satellite data. If you decode the GPS navigation message yourself, or write software that reads satellite clock corrections, the timestamps are in GPS time. You need the offset to convert to UTC.
How do Galileo, GLONASS and BeiDou handle the UTC vs GPS time problem?
GPS is not the only constellation in orbit, and GPS time is not the only timescale.
Galileo (European Union) uses Galileo System Time (GST). GST is continuous, no leap seconds, but its epoch differs from GPS time. GST was set to TAI at 00:00 UTC on 22 August 1999. The offset between GST and UTC is currently 18 seconds, same as GPS, but the offset between GST and GPS time is not zero. It sits around 13 seconds and drifts slowly.
GLONASS (Russia) uses GLONASS Time. Unlike GPS and Galileo, GLONASS Time includes leap seconds. It synchronises to Russian national time (UTC+3), which means GLONASS Time follows UTC with a fixed offset. GLONASS receivers do not need to apply a leap-second correction. The system already handles it.
BeiDou (China) uses BeiDou Time (BDT). BDT is continuous, no leap seconds. Its epoch is 00:00 UTC on 1 January 2006. The offset between BDT and UTC is also 18 seconds as of 2026. BDT is close to GPS time but not identical.
Building a multi-GNSS receiver or processing data from several constellations? Do not assume all timescales match. Each system broadcasts its own offset from UTC. Apply the correct one for each satellite.
The GPS week number rollover: a related quirk
GPS time is represented as a week number (0 to 1023) plus seconds within the week. The week number sits in 10 bits, so it rolls over to zero every 1,024 weeks. About 19.6 years.
- First rollover: 21 August 1999
- Second rollover: 6 April 2019
- Next rollover: 23 November 2038
Each rollover has broken equipment. In 2019, older GPS receivers stopped outputting valid time or position data because their software could not handle the week count wrapping past 1023. The 2038 rollover will hit the same vintage of equipment, plus any newer devices that repeated the mistake.
How to act on the UTC vs GPS time offset right now
| Scenario | What to use |
|---|---|
| Checking your phone clock | Let the receiver handle it |
| Processing RINEX survey data | Apply GPS, UTC offset manually |
| Synchronising a network time server | Use a receiver that outputs UTC |
| Writing GNSS receiver software | Read and apply the broadcast offset |
| Working with Galileo data | Use GST offset, not GPS offset |
| Preparing for 2038 | Check your equipment's week-number handling |