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