
Date: 9 Oct 1998 23:40:07 -0000 From: "D. J. Bernstein" <djb@cr.yp.to> Paul Eggert writes:
which I am calling the ``modified TIME_TAI''
Your time differences break down near leap seconds. Ever watched xntpd try to handle a leap second? Wobble, wobble, wobble, wobble, wobble. Sorry, I don't understand this comment. The modified TIME_TAI has an implementation-defined epoch, but the epoch is supposed to be fixed for the duration of the execution of the program. If TIME_TAI is implemented accurately, then time differences will be accurate in all timestamps covered by the (partial) leap second table available to the implementation. If the underlying implementation is flaky, then obviously the TIME_TAI values will be flaky; but this is a quality-of-implementation issue, not a fundamental flaw in the interface. After that, if you don't record the leap second, Under my proposal, you'd have to record the leap second, if you wanted to implement modified TIME_TAI correctly, and if you had already handed out some modified TIME_TAI timestamps. The solution is obvious: keep a table of leap seconds! There's no other way to handle UTC timestamps correctly. I tend to agree. My proposal generalizes from libtai in that it allows leap second tables that do not go all the way back to 1972, in an attempt to support the sorts of limited implementations that Kuhn mentions; but I see no way around having a table (if only a partial one) if you want to support leap seconds correctly (if only some of them).