Topics In Timekeeping · What Is UTC

How does GNSS time relate to UTC?

Updated Aug 10, 2026 • UTC, GNSS, timing, metrology

Every satellite you can hear is running a clock that is not UTC, and knows it. The relationship between the two comes in two parts, and confusing them is the source of a great deal of muddle.

Part one is a whole number of seconds, and it is boring. GPS Time, Galileo System Time and BeiDou Time are continuous scales that ignore leap seconds, so each sits an integer number of seconds away from UTC — 18 s for GPS and Galileo, 4 s for BeiDou, as of today. Every constellation broadcasts that count, your receiver subtracts it, and nobody thinks about it again.

GLONASS is the odd one out twice over. It is the only constellation that applies leap seconds, following UTC(SU) — and it is offset from it by a flat three hours, which is Moscow. So GLONASS system time is UTC(SU) + 3 h, and the thing that stays constant is the three hours rather than a leap-second count.

Part two is the interesting part, and it is a prediction. Underneath the integer, each constellation’s timescale is steered toward UTC — and how differs in a way worth a sentence, because it is the one place these four systems are not built alike:

• GPS toward UTC(USNO), a single national laboratory’s realization.
• BeiDou toward UTC(NTSC), likewise a single laboratory.
• GLONASS toward UTC(SU), likewise.
• Galileo is the exception: GST has no single national laboratory behind it. It is realized and aligned to UTC by the Galileo Time Service Provider, which works from an ensemble of European timing laboratories rather than one of them.

Every satellite then broadcasts its operator’s estimate of the residual offset. That estimate has to be an estimate, because UTC will not be computed for another month.

Each operator publishes what that residual is allowed to be, and all three current standards land in the same place:

The measured reality is roughly ten times better than that. Over fourteen months of daily BIPM measurements, all three sit within a nanosecond of mean bias and a few nanoseconds at 95%. We know the real figure rather than the specified one because somebody grades it, which is the whole subject of the rest of this page.

Two loops, at wildly different speeds

Keeping that estimate good takes two control loops.

The fast loop is the one that keeps your clock honest: corrections computed on the ground, uploaded, broadcast, and applied in your receiver — refreshed anywhere from every five seconds to every couple of hours.

The slow loop runs through the BIPM. Laboratories compare their clocks, report to Paris, and weeks later UTC is defined for a period already past.

Read the figure as two circuits sharing one set of sensors. The red loop leaves the ground segment, passes through the satellite, is observed by the monitoring stations, and comes straight back to the ground segment to be uploaded again. The black loop starts from those same monitoring stations, goes to Paris, and returns as UTC defined — a value, not a correction, and a value about a period that has already ended.

The obvious thing to say about the slow loop is that you cannot steer to it, and that is true. It is also the least interesting thing about it, because the slow loop is where the fast loop’s homework gets marked. That marking is published, and it has a page of its own: the GNSS prediction scorecard.

The cadences, which are easy to conflate

Three different clocks tick here, on different axes.

Monthly is the batch size, not merely the publication schedule. BIPM’s algorithm processes one month of data at a time, because weighting each clock by its demonstrated stability requires a month of it to look at. The publication cadence follows the algorithm, not the other way round.

Five days is the sample spacing for [UTC − UTC(k)] in Section 1 of Circular T — quoted at “standard dates”, the MJDs ending in 4 and 9, at 0 h UTC. So one Circular T carries about six samples per laboratory, not one.

One day is the sample spacing for the GNSS comparison in Section 4, and for UTCr below. Anything varying faster than its sample spacing is invisible, whichever section you are reading.

And a fourth product for when a month is too long to wait:

UTCr, rapid UTC, published weekly since July 2013 with daily values. Participation is voluntary and requires labs to submit data every day. It agrees with Circular T to within a few nanoseconds.

Latency, measured

Across fourteen consecutive issues of Circular T, the delay from a measurement to its publication runs:

• newest point in an issue: 8–16 days, median 13
• oldest point in an issue: 39–45 days, median 42

So a fresh Circular T tells you about a period that ended about two weeks ago and began about six weeks ago — during which your clock has already done whatever it was going to do.

That is the whole shape of it. The fast loop tells you what to do. The slow loop tells you how you have been doing. Neither substitutes for the other, and a timing programme that consults only the first has no way of knowing whether any of it worked.

Where to go next

• Which GNSS constellation keeps the best time? — what the slow loop actually reports about the fast loop, with fourteen months of it plotted.
• GNSS time is a prediction — the fast loop in detail, and why the correcting happens in your receiver.
• Can I sync my datacenter clocks to UTC? — the slow loop from the inside, and why the answer is literally no, but practically yes.
• Choosing a GNSS timescale for syncing datacenter clocks — having understood the relationship, the decision it leaves you with.