Paul Eggert wrote, quoting me:
Hmm. I am not sure to follow you here, since for the vast majority of applications, struct xtime arithmetic will be defined as following
struct xtime addxtime(struct xtime x, struct xtime y) { return (struct xtime){.sec = x.sec+y.sec}; }
But this gives an answer that can be off by as much as two seconds;
Yes. And this is the current accuracy of *all* applications using the present API.
an inaccuracy like that would break many applications.
I do not think so (given the current state of affairs). While I agree with you that improving the accuracy would be a real gain. Remember that my remark above was just highlighting a *possible* (and quite probable IMHO) behaviour, and certainly not the one I will recommend for the general case.
Your remark reinforces my impression that the struct xtime method is too error-prone in practice.
It looks like we both agree an API to make the basic arithmetic upon the "basic" times would be a gain.
This proposal have a clear drawback: like clock_t in C89, it requires to specify the resolution of the type itself requiring a lot of multiplication/division with a constant like XTIME_PER_SEC
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.
*if* we disregard subseconds, Markus' proposal is essentialy the same as the initial POSIX, isn't it?
Yes; but that's also true for my proposal. If STIMES_PER_SEC is 1, then it degenerates to the original POSIX.1 as a special case.
I missed this point; thanks for making it clear.
Another idea is striking me right now: <snip> Something like that could be done, but it is complicated; if you're going to have that level of complexity, you might as well make struct xtime be an opaque type (xtime_t, say) and be done with it.
That is what I tried to avoid...
This would be a reasonable committee-like compromise that might satisfy neither of us (:-).
:-)
Furthermore, there should be some way for xtime_breakup to disambiguate between UTC and TAI: so one more parameter...
I don't understand this comment. xtime_breakup is defined to work only on TIME_UTC timestamps. There's no need to break up TIME_TAI timestamps.
But it also works if a TIME_TAI value is passed, without any effort. This looks like a nice drawback of Markus' design to me. (I know that from a Standard C' point of view, this is undefined behaviour, so this is not guaranteed to work; however, I do not see how it can fail).
In textual form, I do not see the problem. What is wrong with
fprintf(output, PRIdFAST64 ":" PRIdFAST32 "\n", xt.sec, xt.nsec); then fscanf (input, SCNdFAST64 ":" SCNdFAST32 "\n", xt.sec, xt.nsec);
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[ ! Quite not a problem in practice until some time, I think ! ;-) Antoine