Topics In Timekeeping · What Is UTC

Can I sync my datacenter clocks to UTC?

Updated • UTC, timing, metrology, datacenter

Literally no, but practically yes.

That is not a dodge. Both halves are true, they are true for the same reason, and the reason is worth ten minutes because it settles a surprising number of downstream arguments — about vendors, about specifications, and about how much money a timing programme actually needs to spend.

The literal no comes from what UTC is. The practical yes comes from what everybody does about it.

The literal no: nobody has UTC

Most people picture UTC as something that exists — a signal, a master clock in a vault somewhere, a number you could in principle go and read.

None of that is true. UTC is a virtual timescale. Nothing ticks it. It is computed, monthly, by the BIPM in Paris, as a weighted average of the readings of several hundred atomic clocks held at about eighty institutes worldwide. No single one of those clocks is UTC. The average is.

Virtual and realization — one pair of words that explains most of this

The literature calls UTC a paper timescale, and that is the term of art. But virtual is the more useful word here, because of what it contrasts with.

A UTC(k) is a realization of UTC — literally, a making-real. UTC(NIST) is a physical thing in Boulder that ticks, that you can put on an oscilloscope, that keeps running when the network goes down. UTC itself is none of those. Virtual and realized are opposites; paper and realized are not.

And here is the consequence the whole site turns on. The virtual scale is decided in arrears — BIPM computes what UTC was, weeks after the fact. So a realization cannot be a copy of it, because there is nothing yet to copy. Every realization of UTC is necessarily a prediction of it, including the very best ones, and the difference between them is only how good the forecast turned out to be.

And the average is worked out afterwards. From a talk on getting to the last nanoseconds:

Labs worldwide compare their clocks to the satellites, report to BIPM in Paris, and literally weeks to months after they report what they saw, BIPM defines what UTC was in the past. That’s the reason you really can’t synchronize to UTC today.

That is not a limitation of your equipment. It is what UTC is. The thing you want to synchronize to will not have been decided for another month. No budget fixes that, and no vendor can sell you around it.

The BIPM’s own framing

The attitude the BIPM guys have is that everybody else on Earth is predicting UTC, while we at the BIPM are defining what it is.

Worth sitting with, because it reorganizes the whole subject. Every clock you have ever used, every time server, every GNSS constellation, every national laboratory’s output — all of it is prediction. There is exactly one body doing definition, and it works in arrears.

You cannot synchronize to UTC. You can only predict it.

Every real-time timekeeping system on Earth is estimating a quantity that has not been computed yet. The estimates are extremely good — but the distinction between predicting and knowing is the reason a page like the limits of averaging exists, and the reason your trueness is knowable only in arrears.

What is published, and when

Two documents matter.

Circular T, monthly, gives the differences [UTC − UTC(k)] at five-day intervals for each contributing institute. This is the definitive record: it tells a laboratory, after the fact, exactly how far its own realization sat from UTC.

UTCr, weekly since 2013, is BIPM’s rapid UTC — daily values for a period already past, narrowing the wait without closing it. It is still retrospective, and it is still not the reference that traceability requires.

So even the definitive answer arrives at five-day granularity, a month late. If you want to know what time it was at 14:32:07 last Tuesday, to the nanosecond, the honest answer is that nobody will ever know precisely — only what UTC was doing across that five-day window.

Why it is built this way

It would be simpler to nominate one clock and call it UTC. The reason nobody does is that no single clock is trustworthy enough.

An ensemble is more stable than any of its members. Individual clocks drift, are taken down for maintenance, get replaced, occasionally misbehave. An average weighted by demonstrated stability rides over all of that, and no one laboratory — or country — owns the result.

The price of that robustness is exactly the awkwardness above: an average cannot be computed until the readings are in, and the readings come from all over the world.

The practical yes: predictions this good are as good as the thing

Here is the part that rescues the answer.

Everyone is predicting UTC — but the predictions are extraordinarily good, they are made by people whose entire job is making them, and they are delivered to your building for free. A datacenter clock that is honestly engineered sits within a few nanoseconds of what BIPM will later say UTC was, and we know that because BIPM grades the predictions and publishes the marks.

So “sync to UTC” is a perfectly sound thing to say in a design meeting. It means track a real-time prediction of UTC produced by somebody competent, and know how big that prediction’s error is. Everything else on this site is detail on those two clauses.

Where the literal no starts to bite

The distinction stops being pedantic the moment somebody has to accept your timestamp — a regulator, a counterparty, an auditor. At that point “close to UTC” is not a claim you can defend by pointing at a GPS antenna, and you are in the world of traceability, which is mostly a paperwork problem and is the subject of its own page.

Two ways onward

From here the subject branches, and which branch you want depends on what you are trying to decide.

If you want to understand the mechanism — how the prediction is made, who makes it, how fresh it is when it reaches you, and how anyone knows it was any good:

If you want to make a choice — because there is more than one GNSS timescale you can align to, they cost wildly different amounts, and most people should pick the cheapest one:

Where to go next