Markus Kuhn writes:
The bulk of UNIX software also uses a fixed formula to break the time_t value down to a decomposed yyyy-mm-dd hh:mm:ss time.
That ``formula'' is isolated in a few lines of code that are invoked by the rest of the system. New calendar rules, new time-zone systems, etc. don't require changes except in those few lines of code. In contrast, there are thousands of lines of code that add or subtract time counters to handle real-time differences. This code wouldn't work correctly if the UNIX kernel were modified to follow the POSIX rules. You claim that nobody would notice, but I've seen several complaints about wobbly clock behavior from people who use xntpd to reset their time counters after leap seconds. The bottom line is that I'm running several UNIX systems that provide accurate civil-time displays and accurate real-time differences; I only had to fix a small amount of code. Your systems, on the other hand, have inaccurate civil-time displays and inaccurate time differences; your unimplemented ``solutions'' would require massive code changes. ---Dan
"D. J. Bernstein" wrote on 1999-12-05 01:43 UTC:
The bottom line is that I'm running several UNIX systems that provide accurate civil-time displays and accurate real-time differences; I only had to fix a small amount of code.
I do understand the advantages in your approach of using a true TAI-locked second counter as the Unix time_t value. The really only thing that makes me somewhat uncomfortable about this approach is that if you exchange time_t values across systems or if you archive them, the interpretation of these values becomes fully dependent on the reliable availability of an up-to-date leap-second table everywhere, and that table currently has to be updated every year or so. I simply see logistic problems and hassles to guarantee that an enormous variety of systems gets updated every 12-18 months with a new table and that for times more than 6 months into the future, the TAI time_t <-> broken-down representation is not even predictable at the moment accurately. Your proposal of running Unix clocks internally on TAI becomes in my opinion MUCH more feasable and safer, if leap second tables hadn't to be updated that frequently. Hence my suggestion to USNO/IERS to relax the |UTC-UT1| boundaries and to announce UTC leap seconds a few decades in advance. A freshly installed computer should not require a leap-second table update for the next 30 years and the earth spins reliably enough to make this feasible if we do not insist on the |UTC-UT1| < 0.9 s condition. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
participants (2)
-
D. J. Bernstein -
Markus Kuhn