Bugs #408123, was updated on 2001-03-12 19:36
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=110493&aid=408123&group_id=10493
Category: run-time
Group: None
Status: Open
Priority: 1
Submitted By: Brian D. Carlstrom
Assigned to: Olin Shivers
Summary: Time/date problem
Initial Comment:
Issues related to -1 being both an error indicator as
well as a real time. Multiple related issues are
including, see followup comments.
-bri
From: Olin Shivers <shivers@lambda.ai.mit.edu>
To: scsh@martigny.ai.mit.edu
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
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
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=110493&aid=408123&group_id=10493
|