big-picture comments on your proposed extensions to ISO C <time.h>

Antoine Leca Antoine.Leca at
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
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:
> 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 !  ;-)


More information about the tz mailing list