Poul-Henning Kamp wrote on 2006-01-19 09:46 UTC:
> > http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt
>
> The serious timekeeping people gave up on rubberseconds in 1972 and
> I will object with all that I can muster against reinventing them
> to paste over a problem that has a multitude of correct solutions.
Just for the record, am I right in assuming that your point is already
fully addressed in the UTC-SLS FAQ at
http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/#faqcrit
?
Anticipating your objection, I wrote there:
All other objections to UTC-SLS that I heard were not directed against
its specific design choices, but against the (very well established)
practice of using UTC at all in the applications that this proposal
targets:
* Some people argue that operating system interfaces, such as the
POSIX "seconds since the epoch" scale used in time_t APIs,
should be changed from being an encoding of UTC to being an encoding of
the leap-second free TAI timescale.
* Some people want to go even further and abandon UTC and leap seconds
entirely, detach all civilian time zones from the rotation of Earth,
and redefine them purely based on atomic time.
While these people are usually happy to agree that UTC-SLS is a
sensible engineering solution *as long as UTC remains the main time
basis of distributed computing*, they argue that this is just a
workaround that will be obsolete once their grand vision of giving up
UTC entirely has become true, and that it is therefore just an
unwelcome distraction from their ultimate goal.
I do not believe that UTC in its present form is going to
disappear any time soon. Therefore, it makes perfect sense to me
to agree on a well-chosen guideline for how to use UTC in a
practical and safe way in selected applications.
This issue has been discussed dozens of times here and we all know were
we stand by now. If that is not it, then I can only guess that you did
not understand the scope of this specification:
Rubberseconds were given up in 1972 for UTC pulse-per-second time-codes,
like the ones many time-code radio stations send out. I think everyone
still agrees (me certainly!) that they are not practical there for
exactly the reasons explained in the above Internet Draft. I do *not*
propose to change the definition of UTC in ITU-R TF.460 in any way here.
This proposal is primarily about operating system APIs, where rubber
seconds have been in use "by serious timekeeping people" at least since
4.3BSD introduced the adjtime() system call. Up to 500 ppm rubber
seconds are used today by many NTP servers to resynchronize the kernel
clock, Microsoft's Windows XP NTP implementation is slightly less
cautious and uses "rubber seconds" with up to +/- 4000000 ppm for
resynchronizing its kernel clock. In fact, if you look at *any* form of
PLL (circuit or software), then you will find that its very purpose is
to implement "rubber seconds", that is to implement phase adjustments
via low-pass filtered temporary changes in frequency.
People have been using PLL "rubber seconds" in operating systems for
quite a long time now, and this practice is still widely considered the
state-of-the-art way of implementing a UTC-synchronized clock. All that
was missing so far is a commonly agreed standard on what exactly such a
PLL-rubber-second clock should do near a leap second, such that all PLL
clocks in a distributed system can perform the rubber leap second in
*exactly* the same way.
The above proposal is *not* about redefining UTC in any way. It is
merely a guideline for *interpreting* UTC in Internet Protocols,
operating system APIs, and similar applications. Its aim is to eliminate
the hazards of some of the currently implemented far more dangerous
alternative ways of interpreting UTC in such environments [e.g. those
listed as options 1a) to 1i) in Appendix A]. Some of these alternatives
have caused quite some off behaviour on 1 January in NTP-synced
equipment.
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Received on Thu Jan 19 2006 - 03:08:55 PST