TAI64

[D. J. Bernstein]

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.

---Dan