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

[Paul Eggert]

   Date: Thu, 01 Oct 1998 10:29:34 +0200
   From: Antoine Leca <Antoine.Leca at 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.