"D. J. Bernstein" wrote on 1998-10-08 17:15 UTC:
Antoine Leca writes:
I just need to add 7*86400L to my start value.
Is that actually guaranteed to work with Markus's library?
Yes, it is. That was the reason why some head scratching went into the selection of how xtime_add() and xtime_diff() threat leap second values.
Don't you get an invalid time if nsec starts out above 999999999?
No. Xtime_add first converts 23:59:60.1234 into 24:00:00 before adding the other parameter. A leap second is additional time between 23:59:59.99999 and 24:00:00. This additional time is not available when we go outside the leap second. So we first have to "conceptually" shrink the borders of the leap second to a zero interval, and then the original leap second timestamp gets trapped at 24:00:00 from where you continue with normal arithmetic. An alternative (probably much more intuitive) model of thought for the same behaviour is the following: TIME_UTC does not count leap seconds as real time. It ignores the time inserted by a leap second. Think of it in the following Image: If you drive with your car along the timeline, think of leap seconds as slippery intervals of the street of time where your wheels block and your odometer (xtime_diff) stops and therefore they ignore the leap second. In this model of thought, xtime_add first has to bring you out of the leap second, and then has to add the required time interval in real non-leap time. If you start driving inside a slippery leap second, your odometer doesn't start to count from 0 to 7*86400L before you have left the leap second. If you visualize UTC arithmetic this way, it suddenly becomes very intuitive (at least for me, try yourself). This way, a lot of algebraic properites are nicely preserved by xtime_add and xtime_diff. If they were defined on a single set (not xtime + double), and if we ignore cosmological overflow, then they would form proper group operations.
They (and I) want reliable and mostly straightforward ways to resolve *their* problems, not trying to write convolutate programs to handle the fantasy of Earth movement.
With libtai the programmer simply says what he means:
caltime_utc(&ct,&sec,(int *) 0,(int *) 0); /* gmtime() */ ct.date.day += 7; caltime_tai(&ct,&sec); /* mktime() */
With xtime, the programmer simply says what she means: #define DAY 86400.0 t = xtime_add(t, 7*DAY); In Ada (a language with strong typing and full operator overloading), the equivalent API will look even simpler because xtime_add becomes of course function "+"(Left : Xtime; Right : Double) return Xtime: t := t + 7 * DAY; In an Ada API, you would of course also add function "+"(Left : Xtime; Right : Double) return Xtime; function "+"(Left : Xtime; Right : Long_Integer) return Xtime; function "+"(Left : Xtime; Right : Xtime) return Xtime; function "+"(Left : Double; Right : Xtime) return Xtime; function "+"(Left : Long_Integer; Right : Xtime) return Xtime; but for C this would probably be clumsy and overkill. The implementation of those should be obvious from the xtime_add example.
What exactly is ``convoluted'' about that? How has libtai ``impeded'' time handling?
Beauty is in the eye of the beholder, but I reserve the right to consider my code to be more straight forward. I also do not have to define an equivalent of mktime() with overflow rules as you seem to have, because I add always seconds directly. Look at the tmx proposal to see how convoluted just the proper definition of mktime becomes in that case. Code becomes difficult to read once people start to add months and years via hidden overflow rules, as months and years differ in length. I would feel highly uncomfortable by doing my time arithmetic via mktime()-like functions. That was after all the whole reason for completely abandoning time_t in my proposal.
Markus's proposal is a disaster from the programmer's point of view.
Thank you for your honest opinion. (Wait, so must be POSIX and BSD then, on which my proposal is *very* closely modeled after all ...) Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>