You could just wrap mktime to check for this (rare) case when you do get an
error. Since errors should uncommon, and since the check isn't that
expensive, the overhead should be acceptable.
adam
..tear.along.dotted.line......................................................
In article <qijafmx8amr.fsf@lambda.ai.mit.edu> Olin Shivers
<shivers@lambda.ai.mit.edu> writes:
I would like to describe a fundamental problem with the Unix time system,
two possible ways to deal with it, and my decision as to which one scsh
employs. This is your chance to lobby if you do or do not like my choice.
The Unix function that converts a date value (a structured description of
time,
e.g. "3:24:15 am, September 30, 1985 EST") into a time value (number of
seconds since 00:00:00 UTC, 1/1/1970) is called mktime(). If mktime()
likes the argument you give it, it returns the time value -- an integer.
If there's a problem, it returns -1 to indicate something went wrong.
Consider for a moment the time value assigned to the date
11:59:59 UTC, 12/31/1969
It's -1. The error value. Oops.
Scsh uses the mktime() function; it is called from the Scheme TIME function.
When I first wrote the C code for Scsh's interface to mktime(), I was very
careful about the error value. Scsh only reports an error if *both* mktime()
returns -1 *and* the errno variable is set to a Unix error code.
But not all errors have associated errno codes. So this doesn't work.
Recently, scsh screwed Leif Nixon by silently returning -1 as a real time
value when it was meant to indicate an error. Leif was expecting a value
somewhere in the range corresponding to Spring of 1997. His program ran
forward using -1, a value from late 1969. Oops.
I have decided to change TIME so that it resolves the ambiguity in favor of
errors -- it will always report an error when the time returned from Unix is
-1. So if you try to find out the time for 11:59:59 1969, you will lose.
How do people feel about this? It's really bad to blow up a program just
because the user accidentally tromped some specific date, but it's *really*
bad not to notice when errors happen.
Unix -- there are no correct solutions, just ugly choices.
-Olin
--
Thanks again,
Adam Sah | Mariposa Database Research Group
| 419 Soda Hall
asah@cs.Berkeley.EDU | UC Berkeley Dept of Computer Science
510-642-8072 | Berkeley, CA 94720-1776
|