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

[Tim Shepard]

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.

This will create quite a mess of confusions, in my humble opinion.


The worst of it (that I can think of) will be in the case of NTP.  The
NTP protocol used to synchronize time on systems on the Internet
currently has no way to indicate which time scale it is carrying
(old-UTC or new-UTC), 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 .)

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).

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).

This will make a mess of the NTP world, with some NTP servers
following the new definition of UTC that no longer tracks mean solar
time, and some other NTP servers continuing to provide time that
follows the old definition of UTC (as best as the operators of such
servers can achieve this---someone will have to decide when to insert
leap seconds).


Anybody have a good idea about how to run some NTP servers on the new
leap-less definition of UTC while some NTP servers provide UTC that
continues to follow the old definition of UTC without a lot of
confusion?

Will the NTP pools need to be split administratively into two groups,
new-utc.pool.ntp.org. and old-utc.pool.ntp.org. ?  (I imagine
pool.ntp.org would probably go with the new-utc but I could imagine
some arguing that it should stay with the old utc as that would break
fewer things, from their point of view.  In any case, I expect there
are some servers in the NTP pool today which will need to follow
old-UTC going forward because their administrators are responsible for
the upkeep of equipment that needs to continue to receive a good
approximation to mean solar time.)


I've tried to think of some clever way to keep all this unconfused,
like using different UDP port numbers for the two different versions
of UTC carried by NTP going forward...  but the people who still need
the old UTC for their legacy systems that need a good approximation to
mean solar time likely will not be able to easily switch those systems
to use a different UDP port, so they're going to need to be able to
run NTP carrying the old UTC on the same old UDP port they've always
been on.  This would argue that the new UTC should be on a different
UDP port, but I imagine those making this decision to change the
definition of UTC believe that all systems for which the administrator
makes no specific decision to go with new UTC or old UTC should get
the new UTC which would argue that the new UTC should get the old
port.  So I've failed to figure out a good way to handle this going
forward.


			-Tim Shepard
			 shep at alum.mit.edu