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
----------------------------------------------------------------------
Comment By: Brian D. Carlstrom
Date: 2001-03-12 19:40
Message:
Logged In: YES
user_id=27364
From: Leif Nixon <nixon@softlab.se>
To: scsh-news@martigny.ai.mit.edu
Subject: Re: time/date bugs in 0.5.0
Date: 24 Apr 1997 22:34:26 +0200
Leif Nixon <nixon@softlab.se> writes:
> The reason I wind up in this cond branch is that I'm
getting
> bogus results from time2date() in time1.c. Yes, it's
another
> mktime() call that returns -1. To be precise, this one:
>
> #ifdef HAVE_GMTOFF
> *tz_secs = d.tm_gmtoff;
> #else
> { char **oldenv =
environ; /* Set TZ to UTC \
*/
>
environ=utc_env; /* time
temporarily. \
*/
> tzset(); /* NetBSD, SunOS POSIX-noncompliance
requires this. */
> *tz_secs = mktime(&d) - t;
> environ=oldenv;
> }
> #endif
If I patch this up to set the d.is_dst field to 0 and
to check for -1 return values from mktime(), the 'date'
function returns legal values. The values even denote the
correct time, but I still lose since it is only the first
call to 'date' that returns date values in the local time
zone:
Scsh 0.5
> (define d1 (date))
> (define d2 (date))
> (date:tz-name d1)
"MET DST-2"
> (date:tz-name d2)
"UCT"
> (time d1)
861913321
> (time d2)
861913326
> (date->string d1)
"Thu Apr 24 22:22:01 1997"
> (date->string d2)
"Thu Apr 24 20:22:06 1997"
>
Leif Nixon SoftLab AB
-------------------------------------------------
E-mail: nixon@softlab.se Phone: +46 13 23 57 61
-------------------------------------------------
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=110493&aid=408123&group_id=10493
|