Arthur suggests:

If the *only* reason for adding mktime was "to replace the capability to do. . .arithmetic [on time_t type values]," I'd advocate simply throwing mktime overboard ...

1. What other reasons can folks think of for adding mktime to the standard?

I would favor it just for conversion from a 'struct tm' to a 'time_t'. Lord knows that I looked at enough incorrect versions where someone tried to write it themselves and got lost! Don't ask about my first attempt several years ago...

2. Would it be wise to add a function to the standard to permit arithmetic on time_t type values?

If there are no functions to modify a time_t or to compare one, people will invent several versions. However, this should be a C question. Can the existing practices of using 'long' variables be supported? Didn't the X3J11 people provide some functions? Can one cast from a arithmetic type to a time_t (and still get something reasonable)? I'm not sure this last question can be done if time_t is defined by a manufacturer. I favor providing only a mktime() call and guarentee the portability of arithmetic operations on the fields of a 'struct tm'.

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 don't understand what you mean by "out of bounds" -- the added structure members? bad data for a member? Bob Devine