Proposal for new ISO C 9x time API
eggert at twinsun.com
Sat Oct 10 00:40:06 UTC 1998
Date: 9 Oct 1998 23:40:07 -0000
From: "D. J. Bernstein" <djb at 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
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
More information about the tz