Proposal for new ISO C 9x time API

Markus Kuhn Markus.Kuhn at
Tue Oct 6 19:52:33 UTC 1998

"D. J. Bernstein" wrote on 1998-10-06 17:16 UTC:
> Markus Kuhn writes:
> > Each time one of Dan Bernstein's systems misses a leap
> > second announcement, the TAI value that this system uses from then on
> > will be off by one more second.
> Correct. This means that local times will still be displayed correctly,
> but time differences across N missed leap seconds will be off by N.

What concerns me is:

If you use these erroneous TAI timestamps in communication protocols and
in a distributed system inconsistent TAI-UTC tables are used on the
various nodes to convert back from TAI via UTC to local time, then you
will get wrong local times displayed across the system. If you compare
TAI values in system logs across systems, you will get inconsistencies
(e.g., negative network delays, etc.) => better use UTC.

> In other words: ``Without a leap-second table, libtai performs just as
> badly as Markus's proposal.''

First, I have just posted the 3-line code of how you can use
xtime_conv() and xtime_diff in my API to determine the correct number of
SI seconds between timestamps, so my proposal performs absolutely
correctly despite your continued attempts of misleading rhetoric.

Secondly, in my API the user has a much better chance to find out about
the lack of an up-to-date leap second table, therefore the opposite
statement that in the worst case my proposal performs as badly as yours
is technically probably a bit more justified.

I hope you agree that I have shown how your libtai API can be
implemented in a portable way on top of my xtime proposal without loss
of functionality.

> Ever heard of TCP/IP? How about UNIX?

Well, I vaguely remember having heard about these things once or twice,
but feel free to give me an introduction, since I am quite new to all
these confusing acronyms ...

> How about system logs? Timestamps
> in logs aren't just for clock displays; they're also used for profiling
> and accounting. Time differences are crucial.

Interesting point: I have been told by a phone exchange designer whom I
asked about their timing hardware, that in the telephone industry, it is
common practice not to charge for the traffic during leap seconds. Most
digital phone systems run phase locked with UTC today. I think they have
survived their financial losses of around 0.0000021 percent caused by
leap seconds quite well. Check your contracts to make sure you are not
calculating unrealistic communications costs if you your TAI for such
applications. Similar things apply to power supply companies, although I
am not sure about the details. If I remember correctly, Tanenbaum writes
in his Distributed Systems book that US power companies provide you
every UTC day 86400*60 power cycles, and that they reduce the frequency
to 59 Hz for one minute in the case of an inserted leap second.

So for phone charges and AC power cycles, my xtime_diff on TIME_UTC
provides quite the right semantics. Nice, isn't it? The real world is
ticking in UTC (except of course navigation systems, and even there
GLONASS is ticking in UTC, while GPS is locked to TAI).

> Markus Kuhn writes:
> > and if you think that the Pentium's internal bus cycle counter

> Do you have any idea what you're talking about?

I very much like to think so.

> The bus frequency is much lower than the CPU frequency.

Sure. I think I used technically very precise language and referred
clearly and correctly to the "internal bus", in other words to the
on-chip bus that runs with the internal CPU clock frequency. You will
need a microprobing needle or (especially for the new Pentium) an EBT in
order to make measurements on it. Been there, done that.


Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at,  home page: <>

More information about the tz mailing list