Topics In Timekeeping · What Is UTC

What does "traceable to UTC" actually mean?

Updated • UTC, timing, metrology, datacenter

It means somebody can follow your number all the way back to UTC, one documented comparison at a time, and say how much uncertainty it picked up on the way. That is the whole of it.

What it does not mean is the useful half. It is not a logo, not a certificate, not a vendor’s word, and — the one that catches people — not a GPS antenna. Receiving a signal that ultimately derives from UTC is a fact about the signal, not a chain of comparisons you can show anybody.

Which is why “traceable to UTC” appears in a great many specifications and rather fewer systems.

The formal definition says the same thing exactly, and unhelpfully: metrological traceability is the property of a result that it can be related to a stated reference through a documented, unbroken chain of calibrations, each contributing to the measurement uncertainty.

Every word of that is doing work.

Unpacking it

Documented. Not merely true — recorded. A chain that exists in reality and not on paper is not traceable, because the point is that somebody else can check it. This is the requirement most systems fail.

Unbroken. Every link, from your timestamp back to the definition of the second. One undocumented hop and the chain ends there.

Chain of calibrations. Each link is a comparison somebody made, with a result. “We use GPS” names a signal, not a comparison, and not a result.

Each contributing to the uncertainty. You must be able to state a number and defend where it came from. Traceability without an uncertainty budget is a claim with no content.

Traceable does not mean accurate

These are independent. A traceable measurement can be poor — traceability tells you the path back to the definition is known and its uncertainty accounted for, not that the number is good.

Conversely, an excellent measurement with no documentation is not traceable at all, however right it is. This surprises engineers, because it is a claim about evidence rather than about performance.

What this means when your reference is a constellation

Here is where datacenter reality bites.

A GNSS receiver gives you a prediction of UTC, broadcast by a constellation operator who steers their timescale toward UTC and publishes how they did. That can anchor a traceability chain — the operators’ relationship to UTC is documented and monitored.

But the chain only reaches as far as your documentation does. The links you own are the ones that break:

  • The antenna position you configured, and how you established it.
  • The feedline delay you configured, and how you measured it.
  • The distribution path from receiver to host, and its uncertainty.
  • The record that all of the above was true on the day in question, not merely today.

That last one is the one that catches people. Traceability is a claim about a past measurement. If somebody adjusted the antenna mount in March and nobody wrote it down, your chain has a gap in March, regardless of how good the system is now.

The practical shape of it

Traceability is mostly a records problem wearing an engineering costume. Three things make it real:

  1. A calibration record for every configured constant — the position, the cable delay, the compensation values — with when it was established and how.
  2. An uncertainty budget that adds up, in which each term traces to a measurement rather than to an assumption. This is where the matching argument becomes concrete: you cannot budget for a term you never measured.
  3. A monitoring record showing the system stayed within that budget over the period being claimed — not merely that it was configured correctly once. What to monitor, and why a second source only catches what it does not share with the first, is its own page.

None of that is exotic. All of it is boring, and being boring is exactly why it tends not to get done until somebody asks for it, at which point it cannot be reconstructed retrospectively.

The cheapest time to build a chain is while you have one

Every fact traceability needs is easy to record on the day and impossible to recover later. The delay you measured with a TDR, the survey you had done, the firmware version, the date the mount was last touched — all trivial now, all unrecoverable in two years.

Where to go next