GNSS Time Systems

A blink is a city block

Here is a fact that should feel slightly unreasonable. Light travels about 30 centimetres per nanosecond. A nanosecond is a billionth of a second — the time it takes light to cross a grain of rice. So if a GNSS receiver's sense of time is off by a millionth of a second, it computes distances that are wrong by 300 metres. Off by a whole second? Your fix lands 300,000 kilometres away — most of the way to the Moon.

This is the quiet truth under all of satellite positioning: it is not really a distance measurement at all. It is a time measurement that we multiply by the speed of light and politely call a distance. Which means the entire enterprise lives or dies on one question — whose clock, and measured how?

The idea, before any mathematics

You already met the receiver's own unreliable clock in pseudorange: the bias it adds to every range. But that was only half the story. The other half is that the whole system has to agree on what time it is in the first place — and "what time is it" turns out to have several competing, equally valid answers.

Think of it as a family of clocks, each with a different personality:

• TAI (International Atomic Time) is the stoic. It is the weighted average of hundreds of atomic clocks, and it simply counts — no jumps, no adjustments, no drama, forever.
• UTC (Coordinated Universal Time) is the people-pleaser. It wants to stay in step with the Sun, but the Earth's rotation is slightly irregular and slowly slowing. So every so often UTC inserts a leap second to stay within 0.9 s of the sky. That makes UTC the civil time on your wall — and a timescale that occasionally stutters.
• GPST (GPS Time) is the professional. It is atomic and continuous like TAI, but it was set equal to UTC at one instant — the GPS epoch, 6 January 1980 — and has ignored every leap second since. It has therefore drifted ahead of UTC by exactly the leap seconds it skipped: 18 seconds today.

The punchline is this: GNSS satellites deliberately keep a clock that is "wrong" by civil standards, because a timescale that stutters is a timescale that ruins a position fix. A leap second mid-solution would inject a one-second — a 300,000 km — discontinuity. So the satellites keep smooth, continuous time, and hand the receiver a small offset to apply only when a human wants to read a normal-looking clock.

Atomic time is honest but rude; UTC is polite but jumpy. GNSS chooses honest and rude, then translates for the humans.

Seeing it

Picture three runners on a track who all start together at the 1980 epoch. TAI and GPST are metronomes: they run at exactly the same pace and never break stride. UTC runs alongside them — but every year or two it stops for one second to let the slowing Earth catch up.

Each of those pauses drops UTC one second further behind the atomic runners. Plot the gap over time and you get a staircase: TAI − UTC climbing step by step, and GPST − UTC climbing the very same steps, just nineteen seconds lower. The two atomic lines stay rigidly parallel forever, because the distance between two runners who never break stride cannot change.

Try it yourself

The chart plots how far each timescale runs ahead of UTC, from 1972 to 2035. Drag the green marker through time and watch the panel.

Drag anywhere on the chart to scrub through time. TAI (blue) climbs one step per leap second; GPST (orange) runs exactly 19 s below it and never steps on its own.

Jump to the GPS epoch: TAI − UTC is 19 s and GPST − UTC is exactly zero — the moment the two clocks were set equal. Scrub forward and watch UTC fall a second further behind at each leap, while the gap between GPST and TAI never budges. That unwavering 19 s is the whole reason GNSS keeps continuous time: a receiver should never have to flinch at a leap second mid-fix.

Instant (UTC)2020-01-01

TAI − UTC

37 s

GPST − UTC

18 s

BDT − UTC

4 s

Leap seconds (since 1972)

27

GPS week

2086 (38 of 1024)

GPS time-of-week

259218 s

GPS epoch (1980)Rollover I (1999)Last leap (2017)Rollover II (2019)

Two things to try. First, hit GPS epoch (1980): GPST − UTC snaps to exactly zero, the instant the two clocks were deliberately set equal, while TAI − UTC already sits at 19 s. That 19-second head start is baked in forever. Second, scrub slowly across a leap-second step (say, 2017) and watch UTC lose another second to the atomic pair — while the gap between GPST and TAI doesn't so much as twitch.

Now the mathematics

The relationships are refreshingly simple once the picture is clear. Let $\text{LS}(t)$ be the accumulated leap-second count, i.e. the integer:

$$\text{TAI} - \text{UTC} = \text{LS}(t)$$

which today equals 37 s. The continuous system times are then fixed offsets from TAI:

$$\text{GPST} = \text{TAI} - 19\,\text{s}, \qquad \text{BDT} = \text{TAI} - 33\,\text{s}$$

The 19 and the 33 are not coincidences: they are the values of $\text{TAI} - \text{UTC}$ at each system's epoch (1980 for GPS, 2006 for BeiDou), frozen in at "birth." Subtracting UTC gives the offsets you actually observe:

$$\text{GPST} - \text{UTC} = \text{LS}(t) - 19 = 18\,\text{s} \quad (\text{today})$$ $$\text{GPST} - \text{BDT} = 33 - 19 = 14\,\text{s} \quad (\text{always})$$

That last line is worth savouring: because both are continuous, the gap between GPS and BeiDou time is a constant, immune to leap seconds entirely.

Finally, GNSS doesn't transmit a calendar date. It counts weeks and seconds into the week since the epoch:

$$t_{\text{GPST}} = \text{week} \times 604{,}800 + \text{tow}, \qquad 0 \le \text{tow} < 604{,}800$$

A subtlety the interactive quietly demonstrates: a UTC midnight does not land on a GPS week boundary. It sits $\text{LS}(t) - 19$ seconds late, because the week is counted in continuous GPST while your calendar is UTC. This is exactly why 2020-01-01 00:00:00 UTC is GPS week 2086, time-of-week 259,218 s — that trailing 18 is the leap offset in the act.

How this appears in engineering

The broadcast navigation message carries the parameters to make all of this automatic: the current $\text{TAI} - \text{UTC}$ offset, a scheduled future leap-second value and its date, and inter-system offsets (like the GPS-to-Galileo offset, GGTO) so a multi-constellation receiver can fuse measurements onto one common timescale. Get any of these wrong and the errors are unforgiving and characteristic: a whole-second slip is a ~300,000 km blunder, and the infamous week-number rollover — the broadcast week field is only 10 bits, so it wraps every 1024 weeks (1999, 2019, next in 2038) — has sent poorly-written receivers tumbling two decades into the past. Modern signals widen the field to 13 bits, buying breathing room until the 2130s.

One elegant consequence closes the loop with single point positioning: because the receiver solves for its own clock at every epoch, a GNSS receiver is not just a locator — it is a superb clock, disciplined to national time standards as a free by-product of figuring out where it is. Timing and positioning are two answers from the same equations.

Check your understanding

• A receiver mislabels a measurement's timescale by one whole second. Roughly how far off is the resulting position, and why?
• GPST and TAI differ by exactly 19 s and always will, but GPST − UTC keeps changing. What single fact explains both statements at once?
• Why does a UTC midnight fail to land on a GPS week boundary? What is the exact size of the offset today?
• Leap seconds are being phased out by around 2035. Which timescale stops changing relative to TAI as a result — and which one starts slowly drifting away from the Sun?

Where to go next

Time is the hidden axis under everything in GNSS. It sets when a satellite's position is evaluated along its orbit, it is the receiver clock bias in pseudorange, and it is the fourth unknown that single point positioning solves for. Next in the signal story: how a receiver actually measures these travel times in the first place — by sliding a replica code until it locks onto the satellite's transmission.