Issues related to -1 being both an error indicator as
well as a real time. Multiple related issues are
including, see followup comments.
From: Olin Shivers <email@example.com>
Subject: Time/date problem
Date: 17 Apr 1997 19:58:36 -0400
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
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
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
Log in to post a comment.