Date: Fri, 09 Oct 1998 12:17:31 +0100 From: Markus Kuhn <Markus.Kuhn@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 second....
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 TIME_TAI cannot. And once we have the modified TIME_TAI, we don't need nsec>=1000000000, and this cleans up several infelicities in the current interface. 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 TIMe_MONOTONIC. 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 tables. 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 second 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.