mktime

[seismo!nbires!vianet!devine]

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