[LEAPSECS] UTC going forward, one or two definitions? and what about NTP?

Poul-Henning Kamp phk at phk.freebsd.dk
Wed Aug 14 03:02:29 EDT 2013

In message <E1V9Rwn-0002rc-00 at www.xplot.org>, Tim Shepard writes:

>If ITU-R decides to change the definition of UTC so that no more leap

>seconds will be used to keep it synchronized reasonably well with the

>other versions of UT, but does not change the name of UTC at the same

>time, then after that we will have the situation of two different

>definitions of UTC, and many (all?) uses of the term UTC going forward

>will be ambiguous.

Uhm, no ?

UTC will be defined as three distinct periods:

1) w/ Rubber seconds (until 1972)
2) w/ Leap seconds (1972 until 201x)
3) Continous/Atomic (201x ...)

You can argue that is 50% more potential confusion than today
if you think that clarifies anything.

The only way confusion can happen the way you describe, is if
some sub-tribe decides to implement their own private definition
of UTC, by ignoring the ITU-R plenary decision.

>The NTP protocol [...] and the spec explicitly says that it carries UTC

>*and* *also* *says* that UTC is a time scale that represents mean

>solar time. (See rfc5905.txt .)

UTC without leap seconds still represents mean solar time, now just
with a time-increasing tolerance, rather than the +/- 1 second
bound it has now.

The "skew" will be so slow that nobody will notice it during a
normal lifetime.

>So over the last couple of decades people who needed to build systems

>to provide mean solar time have often built systems that get this mean

>solar time via NTP (which provides it pretty well to within a second).

Well, guess what: They get to use the new high-resolution DUT1
product from IERS, so their mean solar time needing systems can
be much better and precise than they could otherwise.

>If ITU-R decides that UTC will no longer have any leap seconds

>inserted, but some people have systems that currently get their mean

>solar time via NTP, it will be very tempting for them to continue to

>run one or more NTP servers that distribute time via NTP that

>continues to track mean solar time (and network such NTP servers

>together with others in the same situation).

Ohh, just like the "flat earth society" ?

Sure, go ahead. The NTP clock filter algorithm is quite good
at throwing out servers which give bogus time, so that will
confuse nobody, and if it does, it'll be easy to black-ball
the Flat-Earth-Societys NTP server.

>This will make a mess of the NTP world, [...]

That sounds a little bit like "Nice time-synchronization network
you have there, it would be a pity if anything bad happened to it"

I'm sure that's not what you mean ?

>Will the NTP pools need to be split administratively into two groups,

>new-utc.pool.ntp.org. and old-utc.pool.ntp.org. ?

No, why would they ? NTP servers serve current timestamps, they
don't serve old timestamps, so only the current definition of
UTC is relevant.

>I've tried to think of some clever way [...]


Fortunately you didn't manage to confuse anybody but yourself.

Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

More information about the LEAPSECS mailing list