UT1 ("true GMT") as an alternative to leap smearing?

Client Configuration and Development
1

So, just an idea that popped into my head. Not necessarily something I wanna advocate for, especially not in the pool, but though it might be interesting to hear your thoughts on it.

IERS publishes and continuously updates predictions about leap seconds and UT1-UTC offsets. UT1 is basically the good old-fashioned observed time of day, looking at the sun in the sky, and is affected by the rotation of the earth. When we’re having leap seconds, that’s basically just UTC catching up with UT1.

So, what if we, instead of leap smearing, just use the UTC-UT1 offsets from IERS to report GMT/UT1? It’s just as official and universal as UTC, and when everyone else are having to deal with leap seconds, with or without smearing, you’re already there and everyone else are simply catching up.

2

NIST (and possibly others) are actually already providing UT1 as a service. Sounds interesting, though may raise some practical concerns that need to be addressed. In a way, we’d be kind of in constant “smearing” with this, with similar benefits as well as challenges. While the values are published at/for discrete moments in time, they are actually continuous. So it would need to be agreed upon at which instances to take a discrete value, and how to handle the time in between. E.g., linear interpolation, as used by NIST. It is my understanding that a lack of agreement/standardization as to how to implement leap smearing is what keeps it from wider adoption. Different implementations have different algorithms, and those are also tweakable by operators, so it’s not been possible yet to agree on a universally accepted and agreed upon way as to how to smear so that different sources would all agree on the same time.

The other aspect is dissemination of the information. GNSSes and radio systems are nowadays widely supporting dissemination of leap second information. On the IT side, history is a bit more sketchy, with only two “original” sources for the leap-seconds.list file. Since not long ago*, it is finally also being distributed via the TZ database found on many Linux and other systems. Similar distribution mechanisms would need to be established for DUT1 as well. And in case of the tzdata package on Linux et al., this would mean way more frequent updating of the package than is typically supported by many distributions.

Or different ways of dissemination would need to be established, e.g., time daemons directly fetching this information from the sources themselves, or some yet-to-be-established intermediaries. Would need the definition of a common machine-readable format. And sufficient resources on the servers’ side to handle the increased traffic volume from many more clients pulling the data, and way more frequently than in the leap second case. E.g., the leap second file is retrievable via HTTP from the TZ project pages/IANA. Something similar might be conceivable for DUT1.

And not least, NTP carries the leap second indication. Suitable extensions could be defined to carry DUT1.

So all in all, looks generally feasible. But a lot of (alignment) work. With experience from leap smearing not too encouraging as far as seeing results anytime soon is concerned. Maybe in the context of the already agreed-upon activity to look for a long-term solution for/relacement of leap seconds on the ITU level.

* Checked, and it looks like it’s actually been added to the database for the first time some 11 years ago - so quite a while in IT dimensions. And, e.g., ntpd on Debian seems to access it by default since about 7 years.

3

Is the suggestion to distribute and use both UTC and UT1? The potential for confusion is a major concern. Using UT1 exclusively results in a variable duration second. E.g., Cesium clocks cannot maintain UT1 during holdover.

4

I agree with those concerns.

The premise had been that UT1 would be used as alternative to leap smearing. I.e., I inferred that it was intended to address the same problems. I.e., that would implicitly mean that systems, e.g., the Linux kernel, would keep their system time in UT1.

UT1 could easily be propagated through NTP, just like leap smearing is. However, as you point out with the example of holdover, feeding in UT1 “at the top”, i.e., stratum 0, would be difficult, as all current stratum 0 sources keep time derived from TAI. E.g., GPS time in case of GPS, UTC in case of GLONASS, etc.

Thus, not spelled out, but implicitly assumed as backdrop for my previous post was that time at stratum 0 would still be disseminated derived from atomic time, e.g., UTC, for the reason you point out. UT1-UTC would be provided alongside it, or by other means. Then, e.g., stratum 1 would generate UT1 and pass that on within NTP, like done with leap smearing. Or UTC would be passed on, plus potentially UT1-UTC, and lower strata would need to be aware of that, and then derive UT1 locally, and feed that to their systems. I.e., “within NTP”, UTC would be used, and for syncing system time, that would be translated to UT1. A bit similar to what we have now with system time kept in UTC (on typical Linux at least, Windows and others might be different), and local time and possible DST representations being generated from UTC locally for “presentation”.

Fully agree that makes things more complicated. Unless a smarter way to leverage UT1 as replacment for leap smearing could be devised…

But I had understood this to be mostly a thought experiment for now…

EDIT: Actually, thinking about it, I think the option to pass on UTC through NTP, and then have lower strata servers each derive UT1, doesn’t make sense. Limiting the awareness of UTC vs. UT1 to stratum 0 and 1 already causes enough challenges, and smearing that logic across lower strata as well doesn’t seem to bring any benefits, just more issues. If lower stata systems have a need for UTC, e.g., because they operate in environments where UTC (or some atomic time derived scale) is used, they can do so themselves, inverting the stratum 0/1 operation.

5

If changes to the NTP protocol would be made, maybe it would make sense to change to primarily using TAI, and include the offsets for UTC (and possibly UT1) in separate fields within the NTP packet?

Whatever makes for the most interesting discussion :smiley:

That’s what my idea was, yes

Indeed it is.

I don’t imagine it will gain traction anytime soon, and trying to force it through sounds like a nightmare. Even just doing it within the pool is unlikely to catch on among the server operators, partially because of software limitations. Or can Chrony/NTPd/NtpSec already do it without manually setting and regularly updating offsets in the configs?

In that case, they should probably find a source that simply uses UTC. Much like we don’t use Google’s NTP service as a source around here because of their leap smearing :smile:

1 Like
6

There was some discussion on the IETF NTP working group mailing list regarding allowing the use of different timescales in NTPv5. If you’re interested in this it would definitely be worth reading that discussion, along with the couple of drafts related to v5:

And I would strongly urge anyone interested in seeing NTP move forwards to participate in the IETF working group. Even if it’s just to comment about what makes sense based on your experience as a pool operator.

4 Likes