Markus Kuhn <Markus.Kuhn@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. --Ken Pizzini