Proposal for new ISO C 9x time API
eggert at twinsun.com
Mon Oct 5 22:23:59 UTC 1998
Date: Sun, 04 Oct 1998 11:16:52 +0100
From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>
One of the fundamental concepts behind my API is exactly to make sure
that there are only two functions, which would access to a leap second
table, and both are optional, that is are always allowed to return that
they have no information available. These two functions are xtime_conv()
Sorry, I don't follow you here. In your spec, if xtime_get with
TIME_UTC returns a time with nsec>=1000000000, then the application
has obtained a leap second; so xtime_get's implementation must have
accessed a leap second table of _some_ sort.
Normally, one would think that an implementation has only two choices:
(1) Support leap seconds (e.g. the Olson code in "right" mode, or
Bernstein's library); or
(2) Omit leap seconds (e.g. POSIX.1).
It sounds like you're trying to allow for another possibility:
(3) Support just some leap seconds, without having
a complete leap second table.
For example, it sounds like you want to cater to implementations that
know only the leap second nearest to the present, or something like
The leap second table is _always_ incomplete, of course, since we
don't know all future leap seconds; so this problem of incomplete
knowledge of leap seconds is inherent to any high-quality interface.
So I suggest that we give the programmer a way to access to the entire
leap second table known to the implementation. E.g. if the
implementation knows only the next leap second, then it would return
``I don't know'' for questions about later (or previous) leap seconds.
This seems to me to be the most natural way to model implementations
of type (1), (2) and (3).
By the way, I'm not familiar with type (3) C implementations in
practice -- which ones are you thinking of? It would be helpful to
have a bit more familiarity with the real-world issues here.
(Also, this issue needs to be discussed better in the rationale!)
leap second tables are a very dubious and extremely dangerous
A implementation must have a leap-second table of _some_ sort, if only
a partial one, if it wants to support leap seconds; otherwise,
xtime_get with TIME_UTC can't return leap seconds.
I found the nsec overflow to be slightly simpler to implement and
slighly more intuitive. In addition, it does not waste any bits if
only non-UTC clocks are used.
No, struct xtime normally wastes more than two bits, since it puts a
nanosecond value (< 1000000000) into a member that can store numbers
more than twice as large (< 2147483648), and also wastes a sign bit.
Even with TIME_UTC, struct xtime wastes more than one bit.
Here's an encoding that uses about .00001 bit per timestamp, assuming
an integer counter is used for timestamps:
If T is a TIME_UTC timestamp, it identifies the point of time
that is T%D xtime intervals after T/D UTC days after the
epoch, where D is 86401*XTIMES_PER_SEC.
For space-saving this beats all other encodings proposed so far.
In the other proposals for handling leap seconds that I have seen,
almost everything depends on correct leap second tables (especially
in the "let's only use TAI" proposals)
I also would not like to require correct leap second tables.
But I hope that we can do better than the current proposal.
I think the example code I have played around with looks neater.
It would be helpful if you could publish the sample code, when it's ready.
I have considered many alternatives
I know, but we haven't exhausted the alternatives yet! A lot more
thinking needs to be done with this proposal.
More information about the tz