Poul-Henning Kamp wrote on 2005-08-05 12:17 UTC:
> Also, your UTS proposal is a total non-starter: Rubber seconds is not
> a usable solution.
I beg to differ strongly, and I slightly suspect you live a bit in a
dream world with regard to the short-term accuracy that is practical on
most computers (other than dedicated hard-realtime systems):
On paging, preemptive, multi-tasking operating systems that run on
caching CPUs with branch prediction logic, which is what the POSIX
standard addresses (so-called "soft real-time applications"), any form
of second that you can measure is already in practice very noisy and
rubbery.
You may find it a quite challenging exercise to write a POSIX
application that can somehow detect, on its own, that a UTS leap second
is in progress, especially if all its peers also use UTS to answer the
gettimeofday() API call. You'd have to do something rather tricky and
hardware dependent (such as reading out the line counter of your graphic
card's video controller) to get a better than 1000 ppm frequency error
time reference to compare against.
Remember that the frequency error that UTS introduces was carefully
chosen to be
- within a single order of magnitude of the frequency error of the
crystal oscillators commonly used in office and server equipment
- within the physiological sensation limit for duration, speed,
and audio frequency error of most humans
You really need a dedicated experimental setup to find out that a UTS
leap second is in progress if you have no other reference clock.
On the other hand, the traditional NTP kernel driver behaviour, which
brutally subtracts 1 s from the time_t clock at the start of an inserted
leap second (and sets an obscure LEAP flag in an obscure adjtimex()
system call), is trivial to detect. It even breaks monotonicity. It was
designed to allow applications to display 23:59:60.123 UTC during a leap
second, which hardly any application wants to display (other than the demos
normally shown at New Year's Eve parties organized by leap-second geeks .. ;-).
It is merely the current, unfortunately chosen, NTP-driver way of
representing UTC leap seconds on a POSIX API that causes the concerns
that you and others express about leap seconds in this context.
Also note that UTS is only proposed for computer APIs and protocols. It
is *not* proposed for standard frequency transmitters, telecoms frame
frequencies, etc. where UTC as a clock with continuous 1 s ticks works
fine and needs no changes.
See
http://www.cl.cam.ac.uk/~mgk25/uts.txt
for a more detailed rationale.
Markus
http://www.cl.cam.ac.uk/~mgk25/time/leap/
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Received on Fri Aug 05 2005 - 06:04:45 PDT