Fri Feb 6 02:36:13 UTC 1987
> 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?
More information about the tz