GPS Time vs UTC

This article extends the GPS sub-hub with a focused deep dive on the GPS Time / UTC relationship. The /learn/how-gps-works pillar covers operational GPS; /learn/utc-explained covers the civilian time standard; /learn/leap-seconds-explained covers the leap-second mechanism. This article ties them together.

What GPS Time is

GPS Time is a continuous atomic timescale maintained by the USNO Master Clock:

• Epoch: January 6, 1980, at 00:00:00 UTC.
• Rate: SI second (same as TAI).
• No leap seconds — the timescale runs without the periodic UTC adjustments.
• Continuous: never paused, never repeated.

At the 1980 epoch, GPS Time = UTC. UTC had already accumulated 19 seconds of leap-second offset from TAI by then (10 baseline + 9 leap seconds 1972–1979), so GPS Time started with GPS Time = TAI − 19 seconds.

GPS satellites use GPS Time for their internal position calculations. The receiver computes UTC by applying the broadcast offset.

The 18-second offset

As of 2026: GPS Time − UTC = 18 seconds.

The relationship since 1980:

• 1980 epoch: GPS Time = UTC = 0 seconds offset.
• After each leap second insertion in UTC, GPS Time pulls ahead by 1 second.
• 18 leap seconds have been added since 1980-01-06.

The leap-second additions since the GPS Time epoch:

| Date | New GPS-UTC offset | | ---- | ------------------ | | 1981-06-30 | 1 second | | 1982-06-30 | 2 | | 1983-06-30 | 3 | | 1985-06-30 | 4 | | 1987-12-31 | 5 | | 1989-12-31 | 6 | | 1990-12-31 | 7 | | 1992-06-30 | 8 | | 1993-06-30 | 9 | | 1994-06-30 | 10 | | 1995-12-31 | 11 | | 1997-06-30 | 12 | | 1998-12-31 | 13 | | 2005-12-31 | 14 | | 2008-12-31 | 15 | | 2012-06-30 | 16 | | 2015-06-30 | 17 | | 2016-12-31 | 18 |

No leap seconds have been added since 2016, so the offset has been steady at 18 seconds for almost 10 years (the longest pause since UTC was introduced). The CGPM 2022 Resolution 4 will eventually suspend leap seconds; the offset will then freeze.

How GPS broadcasts time

The GPS Navigation Message includes time information:

GPS Time as (week, seconds)

GPS Time is represented as a (week_number, seconds_in_week) pair:

• week_number: the count of weeks since the 1980 epoch.
• seconds_in_week: 0 to 604,799 (seconds in one week).

A specific moment is identified by the pair. For example, July 25, 2025 12:00:00 UTC is approximately GPS week 2375, seconds 432000 (Friday at noon UTC, GPS Time = UTC + 18 seconds).

The Week Number field

The classic GPS Navigation Message (LNAV, on L1 C/A signal) uses a 10-bit Week Number field:

• Values 0 through 1023.
• After week 1023, rolls over to 0.
• Cycle: 1024 weeks ≈ 19.6 years.

Newer signals (CNAV on L2C, CNAV-2 on L5) use a 13-bit Week Number field:

• Values 0 through 8191.
• Cycle: 8192 weeks ≈ 157 years.
• Much less rollover concern.

The leap-second indicator

The Navigation Message also includes:

• Current GPS Time − UTC offset (in seconds).
• Upcoming leap second (within next 6 months, with date).

Receivers process these to compute UTC and to predict UTC behavior during a future leap second.

Time of transmission

Each GPS satellite's message includes the time of transmission from the satellite. The receiver uses this for the pseudo-range computation that underlies positioning.

The Week Number Rollover (WNR)

The 10-bit Week Number field has caused periodic incidents:

August 22, 1999 — first rollover

Midnight UTC August 21-22, 1999: receivers transitioned from week 1023 to week 0. Many legacy receivers (designed assuming counting up from 1980) showed wrong calendar dates from then on, typically 19.6 years off.

Documented incidents:

• Some early GPS-derived clocks failed.
• Some embedded navigation systems showed wrong dates.
• Field-deployed handheld GPS units needed firmware updates or replacement.

April 6-7, 2019 — second rollover

Same mechanism. Receivers that hadn't been updated since the 1999 rollover (or that had been deployed since) faced the same issue.

Documented incidents:

• Some aviation flight management systems had date-display issues until updated.
• Some military and emergency-services GPS units needed urgent updates.
• Power-grid synchronization equipment in some installations had issues.

The 2019 rollover was widely anticipated; firmware updates were pushed in advance. Damage was limited but real.

November 2038 — next rollover

The next rollover for legacy LNAV-using receivers. By that time, most receivers should be using CNAV/CNAV-2 signals with 13-bit Week Number fields and a 157-year cycle. Legacy LNAV-only receivers still in use will face issues again.

Also potentially relevant: 2038-01-19 is the Unix Y2K38 rollover (the 32-bit Unix time overflow). Coincidence rather than connection, but 2038 will be a notable year for time-handling code.

Cross-GNSS timescales

Other GNSS systems use their own timescales:

Galileo System Time (GST)

• Epoch: August 22, 1999 at 00:00 UTC.
• No leap seconds.
• Currently UTC + 18 seconds (same as GPS Time in 2026).
• Maintained by ESA ground stations.

Galileo broadcasts GST plus the GST − UTC offset (similar mechanism to GPS).

BeiDou Time (BDT)

• Epoch: January 1, 2006 at 00:00 UTC.
• No leap seconds.
• Currently UTC + 18 seconds.
• Maintained by Chinese ground stations.

GLONASS Time

The outlier. GLONASS Time tracks UTC including leap seconds, with a constant +3-hour offset for Moscow time:

GLONASS Time = UTC + 3 hours (no leap-second offset)

When a leap second is inserted in UTC, GLONASS Time also inserts it (unlike GPS/Galileo/BeiDou). This makes GLONASS Time directly comparable to UTC plus Moscow offset without applying a leap-second correction.

The trade-off: GLONASS Time has the leap-second discontinuity that GPS/Galileo/BeiDou avoid; on the other hand, GLONASS Time matches Moscow civil time directly.

Modern multi-GNSS receivers

Combine all four timescales:

• GPS Time → UTC: apply broadcast GPS Time − UTC offset (18s as of 2026).
• Galileo System Time → UTC: apply broadcast GST − UTC offset (18s).
• BeiDou Time → UTC: apply broadcast BDT − UTC offset (18s).
• GLONASS Time → UTC: subtract 3 hours.

Multi-GNSS receivers must reconcile these to a common time reference (almost always UTC). Done transparently in modern chipsets.

Why no leap seconds in GPS Time?

The 1980 design choice. Reasons:

Operational simplicity

GPS satellites perform constant-rate timekeeping with atomic clocks. Adding leap seconds would require:

• Periodic firmware coordination across the constellation.
• Risk of synchronization errors during the transition.
• Complexity in receiver processing.

The decision: broadcast the offset, let the receiver handle the UTC conversion. Satellites broadcast pure GPS Time; receivers do the arithmetic.

Continuous time for navigation math

Position calculations use time differences between satellite signals. Continuous GPS Time eliminates ambiguity about whether a difference spans a leap-second transition.

Aviation-safety considerations

Some safety-critical applications can't tolerate unexpected 1-second time shifts. A continuous GPS Time gives those applications a clean reference.

Receiver flexibility

Receivers can display:

• UTC: for human reading (applies the broadcast offset).
• GPS Time: for absolute time-since-epoch (e.g., precise frequency comparisons).
• TAI: GPS Time + 19 seconds.
• Local civil time: UTC + timezone offset.

The user-facing convenience without the satellites having to be involved in timezone or leap-second politics.

What the receiver does

A typical receiver's time-handling workflow:

1. Track the GPS signal: pseudo-range measurements give time-of-flight from each satellite.
2. Decode the Navigation Message: extract GPS Time (week + seconds), GPS Time − UTC offset, any upcoming leap-second indicator.
3. Compute UTC: GPS Time minus the offset.
4. Apply timezone: UTC minus local offset.
5. Display: usually local civil time.

During a leap-second insertion:

• The receiver knows the upcoming leap second from the broadcast indicator (up to 6 months ahead).
• At the insertion moment: GPS Time continues smoothly; the broadcast offset increases by 1; the UTC display shows the famous 23:59:60 second.

Receivers and the rollovers

Y2K-style code in receivers: legacy receivers that assume the GPS Week Number monotonically increases from 0 fail at rollover. Modern receivers include rollover-aware logic:

def gps_week_to_calendar(broadcast_week, current_year):
    # Reasonable assumption: we're not in the year 1999 anymore
    # If broadcast_week is small, assume we're in a later cycle
    if broadcast_week < threshold:
        full_week = broadcast_week + 1024 * rollovers_since_1980(current_year)
    else:
        full_week = broadcast_week + 1024 * (rollovers_so_far)
    return epoch + (full_week * 7 * 24 * 3600)

The trick: receivers must know their approximate current epoch (typically from an internal RTC or last-known time) to disambiguate the rollover. New receivers shipped after 2019 have rollover-aware code; legacy receivers may not.

Precision

GPS Time precision:

• Satellite atomic clock: ±10 ns per day.
• Broadcast time tag accuracy: ±10 ns of USNO Master Clock.
• Receiver time-of-arrival measurement: ±10-100 ns depending on receiver quality.

For positioning math, this nanosecond-precision time is what makes meter-scale positioning possible (1 ns ≈ 30 cm of light travel).

For consumer applications (clock display), the precision is overkill — most consumer apps round to seconds or milliseconds.

For high-precision timing (telecom, financial trading, scientific instrumentation), the GPS Time accuracy is essential and is preserved through specialized timing receivers (e.g., the GPSDO — GPS-Disciplined Oscillator).

Specific use cases

Network time synchronization

NTP (Network Time Protocol) servers often use GPS-disciplined receivers as their primary reference. GPS provides sub-microsecond time to the server; NTP distributes that to clients with millisecond precision.

Financial trading

Stock-exchange trading systems use GPS-derived UTC for microsecond-precision timestamps. SEC's Consolidated Audit Trail (CAT) requires microsecond timestamp accuracy.

Telecommunications

Cellular networks use GPS-derived time for base station synchronization (especially LTE/5G TDD — Time Division Duplex). Loss of GPS sync degrades network capacity.

Power grid

Electric grids use GPS-derived time for PMU (Phasor Measurement Units) — synchronized voltage/current measurements that allow grid-wide state estimation.

Scientific instrumentation

Astronomy, particle physics, geophysics — GPS- disciplined clocks provide microsecond-or-better timestamps for observation correlation across sites.

Common misconceptions

“GPS Time is the same as UTC.” No — currently differs by 18 seconds. The satellites broadcast GPS Time; receivers compute UTC. The offset is significant for sub-second-precision applications.

“GPS handles leap seconds automatically.” The satellites don't; the receiver does. GPS satellites broadcast continuous GPS Time plus the GPS−UTC offset. The receiver applies the offset to compute UTC; during a leap second, the broadcast offset increases by 1, and the receiver's displayed UTC reflects the new offset.

“The Week Number Rollover is a bug.” By design — the 10-bit field was a 1978-era decision when 1,024 weeks felt like a long time. The CNAV/CNAV-2 13-bit field corrects this for future receivers.

“All GNSS systems use the same time reference.” They don't. Each major GNSS has its own timescale with different epochs. Modern multi-GNSS receivers reconcile them all to UTC.

“After CGPM Resolution 4 takes effect, GPS Time becomes UTC.” No — the relationship will simplify (no new leap seconds), but the existing 18-second offset will remain. GPS Time will continue its independent atomic timescale.

“You can ignore the GPS Time / UTC distinction for typical applications.” For consumer apps, yes — the receiver handles the conversion transparently. For precision timing (microseconds or better), the distinction is essential.

“GLONASS Time is more user-friendly because it tracks UTC.” For UTC display, yes, but the leap-second discontinuity in GLONASS Time creates the same issues for high-precision math that GPS Time avoids. Trade-off.

“The 1999 and 2019 rollovers caused catastrophes.” Limited but real. Most modern receivers handled them; legacy and embedded systems often needed firmware updates. The 2038 rollover will be similarly manageable for current receivers (with CNAV/CNAV-2 having longer cycles).

“Receivers know about future leap seconds automatically.” Only within ~6 months. GPS broadcasts upcoming leap seconds within that window. Anything further out: receivers don't know.

“Pre-2017 receivers know about the 2017 leap second pause.” Most receivers handle 'no new leap seconds' gracefully; the broadcast indicator simply doesn't announce any new ones. Receivers continue using the existing 18- second offset.

“GPS Time is unique among GNSS.” Galileo (GST) and BeiDou (BDT) use the same design pattern (continuous atomic time + UTC offset broadcast). GLONASS is the outlier with leap-second tracking.

“You need an atomic clock to use GPS Time.” No — the satellite has the atomic clock; the receiver just needs to read the broadcast time. Inexpensive consumer GPS chipsets provide microsecond UTC.

“CNAV/CNAV-2 deprecates LNAV.” Coexisting, not deprecating yet. LNAV (the classic L1 C/A message) is still broadcast for backward compatibility with the vast installed base of legacy receivers. CNAV/CNAV-2 are additional messages on L2C and L5. Modern receivers can use either or both.

“The 2019 rollover was the last.” For LNAV-based 10-bit Week Number, the next is ~November 2038. For CNAV/CNAV-2 13-bit Week Number, the cycle is ~157 years — effectively never. The 2038 rollover will affect legacy LNAV- only receivers still deployed.

“Multi-GNSS reduces time precision.” Often improves it: more satellites visible → better geometry → better timing solution. Modern multi-GNSS receivers achieve sub-microsecond UTC routinely.

“The CGPM Resolution 4 change is imminent.” By 2035. The resolution mandates suspension by or before 2035; specific implementation details and exact transition date are still being finalized.