Why PToB is standardizing on UTC
The decision to end leap seconds lets us keep UTC simple for small clients while retaining a clear path to TAI and PTP environments.
UTC precision instrument
Mesh epoch reporting
GNSS and PTP diagnostics
We have decided to standardize PToB on Coordinated Universal Time (UTC). Our clients should receive time they can use directly for clocks, logs and measurements, with TAI offset compatibility available for systems that need it.
We had been considering a move to International Atomic Time, or TAI, to align more closely with the Precision Time Protocol (PTP) timescale. The recent decision to make UTC continuous changes that tradeoff. It gives us a simpler foundation for the small microcontrollers at the edge of the mesh.
What the leap second decision changes
UTC and TAI run at the same rate, but UTC has used leap seconds to stay close to the Earth’s irregular rotation. On 15 October 2026, the General Conference on Weights and Measures adopted the next step: continuous UTC takes effect on 20 May 2027. The permitted difference between UTC and Earth rotation time, UT1, increases to one hour, allowing UTC to remain continuous for several centuries. BIPM Resolution 5 sets out that change.
Today, TAI is UTC plus 37 seconds. The new arrangement makes that a stable offset for the foreseeable future, removing the recurring leap-second changes that complicated conversion. Historical timestamps still need the offset that applied at their date. NIST’s leap-second record documents the current offset and earlier changes.
For PToB, that removes a major reason to move the whole mesh to TAI.
UTC at the client and TAI where needed
Distributing TAI would leave each microcontroller that needs UTC responsible for applying the correct offset. The arithmetic is small; keeping the offset valid and consistent across devices, firmware versions and source changes is the extra responsibility.
Our choice is to make UTC the standard time we provide. A sensor can timestamp an observation, an instrument can show the time and a client can write a log without first managing a separate TAI-to-UTC conversion.
For interfaces that expect TAI, the current relationship is straightforward: TAI = UTC + 37 seconds. We can offer that conversion at the interface while keeping one UTC convention throughout PToB. Adding the offset changes the time representation; it preserves the clock’s precision and uncertainty.
A PTP bridge will still need to carry the right domain, timestamp epoch and time properties. PTP explicitly represents the UTC offset and its validity. Matching the timescale is one part of interoperability, and this decision gives us a clear basis for that work.
A mesh epoch that survives a new grandmaster
Alongside the timescale decision, we have been working on the mesh’s own epoch: the identity of a running mesh, initialized when it is created.
That epoch persists through grandmaster transitions as long as at least one participating node keeps the mesh alive. A replacement GM inherits the existing epoch from surviving membership. If the entire mesh goes down, a fresh start establishes a new epoch.
This lets clients distinguish mesh continuity from the lifetime of a particular GM. Source changes still require fresh timing maps and the normal qualification checks; retaining the epoch preserves the mesh’s identity through those changes.
A precision instrument for inspecting the mesh
Our new CoreS3-SE clock brings these ideas onto a display inspired by classic precision instruments: a prominent UTC readout, recessed measurement windows and clear status annunciators.
We are also adding over-the-air GNSS and PTP quality diagnostics for clients to consume. Authenticated reports expose the selected source’s GNSS fix, PPS and qualification state, satellite count, HDOP, and the clock class and priorities used by the mesh election. Clients can inspect those reports alongside their timing path and local receiver quality.
These reports describe the source. They do not grant timing permission or establish calibrated UTC accuracy. The instrument keeps reported source status separate from its own receiver measurements and identifies cached reports when they age.
The CoreS3-SE target is now available on GitHub, with a build and installation guide and diagnostic field documentation for anyone who wants to explore the instrument and the reports behind its displays.