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

[Poul-Henning Kamp]

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 [...]


Indeed.

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.