[LEAPSECS] UTC going forward, one or two definitions? and what about NTP?
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
>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