the ``need'' for POSIX times
ken at halcyon.com
Fri Oct 9 18:37:24 UTC 1998
Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk> wrote:
> 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.
Which reminds me. I think that there _should_ be an API for doing
date arithmetic, and I agree that mktime() is problematical with its
auto-normalization rules having to guess at what the application
programmer was trying to do. Perhaps something like:
struct tm add_tm(struct tm base, struct tm delta);
This, to compute the date six months and three days before date X:
struct tm d;
d.tm_hour = d.tm_min = d.tm_sec = 0;
d.tm_year = 0;
d.tm_mday = -3;
d.tm_mon = -6;
newX = add_tm(X, d);
Now the API itself needs a fair bit more thought than I've given it;
I'm just tossing this one out as a starting point for discussion.
But I feel strongly that it is an important function to have.
Application programmers are likely to get things like leap year
rules wrong (whether from ignorance or laziness), yet the desire to
use these non-constant-number-of-second intervals is fairly common.
Since routines such as xtime_breakup() already need to have full
knowledge of the structure of our calendar, it makes sense to make
use of this knowledge for broken-down date arithmetic also.
More information about the tz