Olin Shivers <shivers@lambda.ai.mit.edu> writes:
> 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.
Unix time is only meant to represent times after 1/1/70. So I can't
see the problem. If it returns -1 it is an error - an unrepresentable
time value. After all, if you pass in a 1969 value and convert it back
again you will get a time in the year 20?? which sounds like the
source of lots of subtle bugs. Better to always return error I think.
Of course for many applications this is unacceptable, in which case
you are forced to re-write Unix time routines to not have this
limitation which is the Right Thing but incredibly hard to do.
Am I missing something?
|