big-picture comments on your proposed extensions to ISO C <time.h>
Antoine Leca
Antoine.Leca at renault.fr
Thu Oct 1 08:29:34 UTC 1998
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
More information about the tz
mailing list