mktime

[Guy Harris]

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).