Topics In Timekeeping · GNSS

Choosing a GNSS timescale for syncing datacenter clocks

Updated Aug 12, 2026 • UTC, GNSS, timing, datacenter, buying

Skip the details — take me to the bottom line ↓

Once you accept that you cannot sync to UTC itself, a question appears that most people never realize they are answering: whose prediction of UTC are your clocks actually on?

You always end up on somebody’s timescale. The interesting part is that the answer is decided not by your receiver but by where your corrections come from — because a correction is computed against some datum, and applying it puts you on that datum. Choose the correction source and you have chosen the timescale, whether or not you meant to.

There are three ways to do it.

The three choices

Read down the “you end up on” column and the pattern is the whole page: each step buys accuracy by tying you to a narrower and more specific definition of what time it is.

a. SPP against a constellation timescale — and this is probably you

SPP uses only what the satellites already broadcast. No internet, no subscription, no convergence time, nothing to register for. Your clock lands on GPS Time or Galileo System Time or BeiDou Time, and the broadcast UTC parameters convert that to UTC for you.

Most readers should stop here, for two reasons that are easy to miss.

First, the constellation timescales are good. BIPM’s prediction scorecard puts GPS, Galileo and BeiDou all within about a nanosecond of mean bias against UTC, over fourteen months of daily measurements. That is not a marketing figure; it is the body that defines UTC, marking the homework.

Second, and more important: if your requirement is that your own clocks agree with each other, the constellation’s prediction error is common-mode and cancels entirely. Everyone tracking GPS shares the same error, so it subtracts out of every comparison you make inside your estate. Paying to remove an error that already cancels is the most common way to waste money in this field.

b. Float PPP against a provider’s timescale

Float PPP adds the carrier phase and replaces the broadcast corrections with precise orbits and clocks from a correction service. The satellite’s own error stops mattering, because you are no longer relying on the satellite’s estimate of anything.

What you gain in accuracy you pay for in specificity: you are now on the correction stream’s datum, not the constellation’s.

Galileo HAS is the one most people will actually use

HAS — the Galileo High Accuracy Service — is broadcast as a separate signal-in-space on E6-B. Free, global, no internet, no subscription, no registration, and far fresher than the broadcast navigation message. Its first phase carries no phase biases, which pins it firmly in this row: it is a float-PPP source and cannot be anything else yet.

That combination is why I expect it to dominate this tier. Every argument against a commercial correction service — cost, a contract, a dependency on somebody’s network, a datum you cannot inspect — evaporates when the corrections arrive from the sky for nothing. If you are considering row (b) at all, price HAS first and make the paid option justify itself against it.

And the commercial example, because its spec sheet is unusually honest

Fugro’s AtomiChron is worth reading even if you never buy it, because its own specification sheet makes the tradeoff unusually legible. It quotes <1 ns to the “Fugro AtomiChron timescale” and <5 ns to UTC — the tight number is against Fugro’s own realization, and the looser one is against the thing the regulator cares about. A separate UTCk tier is sold specifically to close that gap by tying the service to UTC(NIST) and UTC(PTB).

Whether AtomiChron resolves carrier-phase ambiguities is not publicly documented. The receiver-side manuals describe applying a “Fugro composite bias” and say nothing about ambiguity fixing, and Fugro’s marine positioning products do PPP-AR, so guessing either way would be easy.

The link budget argues against it, and it is worth walking through because the reasoning generalizes to any correction service that will not tell you what it does.

c. PPP-AR against one analysis center’s datum

PPP-AR fixes the carrier-phase ambiguity to the integer it physically is. Doing so needs satellite phase biases, and those are only self-consistent when every product in the solution comes from the same analysis center. Mix two sources and the property that makes fixing possible is destroyed.

Which means this row is the most specific of all: you are not on “a precise timescale”, you are on CNES’s datum, or CAS’s, or WHU’s, and switching analysis centers is a change of reference, not a change of supplier.

As far as I know there is no commercial timing service offering this today. It is the path my own PePPAR-Fix work is on, and the reason it is interesting is exactly the reason it is not yet a product.

The fourth answer: don’t choose a GNSS timescale at all

Everything above treats GNSS as a time source. There is an entirely different posture, and for anyone whose real problem is traceability rather than accuracy it is often the right one: treat GNSS as a transfer medium and get your time from a national laboratory directly.

NIST’s Time Measurement and Analysis Service (TMAS) is the worked example. NIST installs a tri-band GNSS receiver at your site — the equipment stays NIST’s property — takes the 1 PPS output of your own clock, and runs a common-view comparison against UTC(NIST). Both ends observe the same satellites at the same moment and difference the results, so the satellite’s clock error appears on both sides and subtracts out. Data goes to NIST every ten minutes and you read the answer in a browser.

The distinction is worth being precise about, because it is easy to file TMAS under choice (b) and it does not belong there:

• (a), (b) and (c) put you on a GNSS-derived timescale. GNSS is the source.
• TMAS puts you on UTC(NIST), a real UTC(k) maintained by a national metrology institute. GNSS is only the wire.

It is also a measurement service rather than a steering one — the base tier tells you how far your clock is from UTC(NIST), with time uncertainty under 5 ns and frequency uncertainty near 1×10⁻¹⁴ at one day, and leaves the correcting to you. NIST sells a disciplined-clock tier separately for customers who want the loop closed.

If the question behind your project is how do I prove this to an auditor rather than how do I get closer, this row deserves a serious look before any of the three above. It is the shortest traceability chain money can buy.

And it raises an obvious follow-up, because NIST publishes its observations the same way PTB and the Royal Observatory of Belgium do: could you skip the bundle and build the link yourself? The measurement, yes — the data is free and anonymous. The claim, no. That question has its own page.

How to decide, in one pass

1. Do your clocks only need to agree with each other? Then take (a), pick any constellation but GLONASS, and spend the money on the antenna and an afternoon on measuring your feedline delay instead — that is where your error actually is.
2. Does somebody outside your estate have to accept your timestamps? Then your problem is traceability, and the fourth answer is on the table.
3. Do you genuinely need to beat a few nanoseconds to UTC? Then (b), and read the specification carefully for which timescale each quoted number is against.
4. Are you doing research? Then (c), and you already knew that.

Where to go next

• Questions to ask a clock vendor — once you know which row you are in, these are the questions that reveal whether the vendor does.
• GNSS time is a prediction — why the corrections exist at all, and why they are applied in your receiver.
• Matching acquisition and distribution — there is no point acquiring time this well and then distributing it badly.