Date: Thu, 01 Oct 1998 10:29:34 +0200 From: Antoine Leca <Antoine.Leca@renault.fr>
But any time proposal must specify the resolution somehow. struct xtime specifies it as nanoseconds, for example; so there is an implied XTIME_PER_SEC value of 1000000000. I don't see this as a special drawback of my proposal.
I beg your pardon to make it clear: it requires the cost of the multiplication/division. Markus' proposal, OTOH, permits to avoid it (at the cost of accuracy, as you highlighted), or to reduce it to the minimum. I don't see why struct xtime will be more efficient in terms of multiplication and division; on the contrary, I think it's less efficient. At the low level, few clocks operate at exactly 1-ns speed, so struct xtime will need to be implemented by multiplication and division internally. (This is what Solaris 2.6 does for struct timespec, for example.) Under my proposal, this multiplication and division could be avoided. You're right that if the user needs to do time arithmetic, he may well have to do some multiplication and division; but that's pretty much inevitable: it's true even for the struct xtime proposal. On the other hand, if the user doesn't need to do any time arithmetic, then under the single-integer proposal it's possible that no multiplication or division will need to be done at all, even internally; the user will be dealing directly with the hardware clock value. This is a win.
That code doesn't report overflow well if the destination host's sec field is smaller than the source's.
This will require having a value outside the range ]-1<<63s, +1<<63s[... that is almost ]-300 Gyears, 300 Gyears[ ! You're right that this is obviously not a problem in terms of what times the clock will return, but it is a problem for routines that need to print and read clock values reliably, regardless of what the values are.