D. J. Bernstein wrote:
Markus Kuhn writes:
If you are *really* interested in the number of SI seconds between two UTC timestamps (very few applications will really need this,
But they *are* applications that need it, right?
Timestamps in logs aren't just for clock displays; they're also used for profiling and accounting. Time differences are crucial.
Why do you refuse to admit that clocks are used this way?
OTOH, your API impedes the use Markus is speaking about (discarding leap seconds), and that is a nuisance sometimes. (Many people are *very* comfortable with the fact that a day is 86400 seconds, not a pseudo-random value...) The only reasonable solution is to have the option. Currently, the only API which gives me the choice one way or another is Markus', provided that every struct xtime parameter may be tagged with the information whether it is really TIME_TAI *or* TIME_UTC (as defined by Markus, with the added point that the calendar should be the proleptic Gregorian). This is the very reason why I prefer Markus' solution: it allows to handle nicely *both* kinds of clocks. OTOH: - C89 is incomplete in this area - Posix states: I support only UTC without leap seconds; that is brocken from the QoI point of view - C9X states: once the number of leap seconds for a timestamp is determined (as per mkxtime or zonetime), this cannot be changed*, effectively giving us a new clock scale that happens to coincide with UTC for a lmited range of time: that is brocken *: unless you specificaly add: tmx.tm_leapseconds = _NOLEAPSECONDS; before calling mkxtime a second time; IMHO, this is a nuisance, and it won't be done this way by programmers. - Mr Bernstein only provides TAI as a basis: while I agree the same effects can be achieved, I believe this is not that natural to most people (in particular, there is a danger if struct tai is transported from one host to another if they disagree about the leap seconds table: effectively, this means either *every* hosts should have an uptodate leapsecodns table, which is unrealistic, or either struct tai should not be exchanged, then why specifying it?
and those usually will better use TIME_MONOTONIC instead of UTC
Do you expect people to record two clocks in their logs? A single TAI clock is better for everybody.
I disagree. This is the same as saying: "English is better for everybody", or "Euro is better for everybody". While I agree with the second ;-), I disagree with the former. YMMV ;-) Also, while TAI timestamps might be better, this is certainly not what is happening: everybody uses UTC (or LT) timestamps, usualy in textual form with :60 indicating leap seconds. This is certainly equivalent, but this is not the same. Antoine