Now that new requests for addition to the tz mailing list have tapered off
(and now that the snows have stopped here in the Washington, D.C. area)
I'd like to note a problem in the October, 1986 version of the
Rationale document that accompanies the draft proposed C standard,
and then ask some questions.
The part of the Rationale document that I'm troubled by is section 4.12.2.3
on the mktime function:
> mktime is an invention of the Committee to complete the set of time
> functions. With this function it becomes possible to perform portable
> calculations involving clock times and broken-down times.
>
> The rules on the ranges of the fields within the *timeptr
> record are crafted to permit useful arithmetic to be done. For
> instance, here is a paradigm for continuing some loop for an hour:
>
> #include <time.h>
> struct tm when;
> time_t now;
> time_t deadline;
>
> /* ... */
> time(now);
> when = *localtime(now);
> when.tm.hour += 1; /* result is in the range [1,24] */
> deadline = mktime(when);
>
> printf("Loop will finish: %s\n", asctime(when));
> while (difftime(time(0), deadline)>0) whatever();
>
> The semantics of mktime guarantees that the addition to the tm_hour
> field produces the correct result even when the new value of tm_hour
> is 24, i.e., a value outside the range ever returned by a library
> funciton in a struct tm object.
>
> One of the reasons for adding this function is to replace the
> capability to do such arithmetic which is lost when a programmer
> cannot depend on time_t being an integral multiple of some known time
> unit.
Ignore the grammar and coding errors for the moment. The big problem (to me) is
that code like the above is not a "paradigm for continuing some loop
for an hour"--you may end up continuing the loop for two hours
(or for no time at all) if the loop is executed just before a
daylight saving time transition.
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 and specifying a function such as
time_t addsec(time_t base, long seconds)
to allow the arithmetic to be done. But the Rationale says that allowing such
arithmetic is just "[o]ne of the reasons."
And now, the promised questions:
1. What other reasons can folks think of for adding mktime to the standard?
2. Would it be wise to add a function to the standard to permit arithmetic on
time_t type values?
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?
--
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA
DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.
