I'm not sure if this got out, so... 1. What other reasons can folks think of for adding mktime to the standard? The reason I've wished UNIX had such a function is that it can be useful to have an inverse to "localtime". I'm not sure it really needs to be in the standard, though; there are things that can be done in a C environment (one that is not necessarily a UNIX/POSIX environment) with the results of "localtime" or "ctime" (namely printing them), but I'm not sure what you can (or, at least, would want to) do with a time value converted from local time. It seems unlikely that somebody would actually wait for some moment of time by looping and repeatedly testing the current time, as given in the Rationale. In a UNIX/POSIX environment, "mktime" would be quite useful. I'm not sure whether it needs to be present in all C environments or not. Perhaps X3J11 should hand it over to 1003.1? (If they do, I can think of a few other things they should hand off as well!) 2. Would it be wise to add a function to the standard to permit arithmetic on time_t type values? There already is one such function, namely "difftime". A function like "addtime" (although possibly with a "double" rather than an "int" argument, since "difftime" returns a "double") not only fits in well with "difftime", but provides a capability that is missing. It's like pointer subtraction and pointer/integer addition; having the former without the latter seems silly. 3. If an arithmetic-permitting function was available, would it be wise to eliminate the ability to handle tm structures containing "out of bounds" values from mktime? I'd be inclined to do so; I don't see the reason why they even put the ability to handle "out of bounds" values now. It seems to me that a program could just as well do the mixed-radix arithmetic entirely by itself, without getting a half-assed assist from "mktime", which seems to be what they intended. They should either have provided a function to add two "struct tm"s (where the second one represents an interval, and need not represent a valid time - e.g., you could represent "25 hours" either by "tm_hour" being 25 or "tm_min" being 25*60), or, at least, provided a separate function to "canonicalize" a "struct tm", instead of burying it in "mktime" (I could imagine a program wanting to do arithmetic on dates and times with both the values and the result being in mixed-radix form, so that they would never bother with any "time_t" value).