D. J. Bernstein
djb at cr.yp.to
Mon Jun 1 04:56:15 UTC 1998
Markus Kuhn writes:
> code that subtracts time usually does
False. Almost all time-handling code
(1) computes a real-time difference (a ``timing'') as the difference
of two current-time measurements or
(2) converts a current-time measurement to a local-time display by
calling the appropriate system library routine.
Why do you persist in ignoring #1? (Answer: Because that code is not
compatible with your religious views.)
> t = t + "one day".
[ ... ]
> what you get is the same time on the next day,
Nonsense. What's the ``same time on the next day'' after 23:59:60 UTC?
Anyway, code of that type generally does not mean what you say it means.
See http://pobox.com/~djb/docs/time/01.txt for an example.
> So NTP does not provide
> the information to convert reliably between UTC and TAI.
False. The client can keep its leap-second table continuously up to
date, provided that the server uses the leap-second warnings properly.
(The fragility of this system is one of the obvious reasons that a new
protocol would be a good idea.)
> gettimeofday(). It is low-pass filtered to smooth out leap second phase jumps
> over a couple of minutes,
[ ... ]
> What is wrong with this clock API?
It's shoddy engineering. You're producing occasional 0.8% errors in
timings and occasional 1-second errors in local-time displays.
> Implementing the correct leap year formula
> when using a 32-bit time_t would just demonstrate the programmer's
> ignorance of the int overflow.
Using the wrong formula is incredibly shortsighted. Many systems will
switch to a 64-bit time_t within the next few years.
More information about the tz