Proposal for new ISO C 9x time API
eggert at twinsun.com
Fri Oct 9 20:06:49 UTC 1998
Date: Fri, 09 Oct 1998 12:17:31 +0100
From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>
> (1) TIME_MONOTONIC is monotonically nondecreasing (hence its name),
> whereas TIME_TAI can go backwards when the clock is reset.
Well, that is just an immediate and direct unavoidable consequence of
having a known epoch.
True, but it's an important consequence that is not immediately obvious
to most people, so when describing the difference between TIME_MONOTONIC
and TIME_TAI it's definitely worth mentioning.
> (2) TIME_MONOTONIC's seconds may start right in the middle of a TAI
I do not see what advantages it has to have the fourth clock type that
you propose, which seems to be identical to TIME_MONOTONIC, except that
the difference to TIME_UTC and TIME_TAI is regulated to be an integral
number of seconds. What is so special about the second ticks here?
Because this fourth clock type (which I am calling the ``modified
TIME_TAI'') can be implemented easily from NTP and DCF77 without
complete leap second tables; whereas the original struct xtime
And once we have the modified TIME_TAI, we don't need
nsec>=1000000000, and this cleans up several infelicities in the
If prefer not to have such a rule in TIME_MONOTONIC, because this then
allows arbitrary precise and constant frequency of TIME_MONOTONIC, while
in your proposal you would have to introduce a phase control loop into
Sorry, I don't understand this comment. I wasn't proposing to change
TIME_MONOTONIC; I was proposing to change TIME_TAI. TIME_MONOTONIC
can stay as it is.
xtime_conv() is perfectly happy if TIME_MONOTONIC-TIME_UTC is 1234567.89
seconds before a leap second and 1234568.89 after a leap second.
Agreed. Let's leave TIME_MONOTONIC alone.
You can easily construct the time you are talking about in your application
the following way:
Yes, one can construct modified TIME_TAI, given the original TIME_TAI.
But my point is that the modified TIME_TAI is easier to implement than
the original TIME_TAI, and it has more useful properties in practice
(in particular, it means we don't need nsec>=1000000000).
Another way to put it is that the modified TIME_TAI is a
generalization of the original TIME_TAI, one that places less of a
burden on implementations than the original TIME_TAI proposal. It
allows high-quality implementations with full leap second tables, but
it also allows lower-quality implementations that have only partial
if you ever run into an application, where you
need this PPS-synchronized monotonic time, please let me know.
The application I'm thinking of is one where the original TIME_TAI is
not available, but the modified TIME_TAI is available, and we want to
support leap seconds within the window supported by the partial leap
second table. From what you've written earlier, this is common with
implementations that get times from NTP and DCF77 but do not have
complete leap second tables.
you try to redesign and restrict my API to make it implementable on
top of a restricted pseudo-TAI like clock model. Why do you think
this is a good thing?
Because the C standard ought to be broadly applicable. It ought to
allow high-quality implementations like Bernstein's or Olson's "right"
mode, as well as lower-quality implementations like POSIX.1, and also
medium-quality implementations like NTP without full leap second
tables. The standard should not require high-quality implementations,
as that's unrealistic; but also, it should not require low-quality
implementations, as they don't suffice for some applications.
My basic argument is that if you use just an integer, most algorithms
will get more complicated if you provide for leap seconds,
I disagree. Let's try to resolve this argument by doing things both
ways, and seeing which works better. I'll write up a spec that uses
integers, and which has the functionality of struct xtime, and then we
can see which is easier to use on some realistic examples.
Using tz_jump in order to test whether a given leap second is known or
not is also trivial: you set nsec=0 and sec-- in the suspected leap
It's a bit more complicated than that, since you can't always subtract
1 from sec, as this might overflow. Of course this can be worked
around, but the interface is trickier than it could be.
If it returns the same leap second, than the system know about
it. If it did not, then either the system has not been informed
about the leap second, or what you have is a bogus leap second. We
never can distinguish for sure between the two cases anyway
Yes we can! For example, the implementation can know that there is no
leap second _tonight_. There ought to be some way that the programmer
can get this information, if available.
> How can the implementation be based fundamentally on TAI but not know
> the TAI epoch?
> Because it gets its timestamps from GPS?
GPS *does* output both TAI and UTC. You are probably more thinking about
time services like NTP and DCF77
Yes, that's what I was thinking about. Sorry about the confusion.
More information about the tz