Bugs item #440376, was opened at 2001-07-11 05:01
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=110493&aid=440376&group_id=10493
Category: run-time
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Sperber (sperber)
Assigned to: Olin Shivers (olin-shivers)
Summary: tm_isdst isn't always set correctly
Initial Comment:
From: Alan Bawden <Alan@LCS.MIT.EDU>
Subject: tm_isdst
To: scsh-bugs@zurich.ai.mit.edu
Date: Sun, 24 Jun 2001 20:29:09 -0400 (EDT)
The documentation for the `time' function promises:
Outside of these boundary cases, the `summer?' flag
is ignored. For
example, if the standard/summer change-overs happen
in the Fall and the
Spring, then the value of `summer?' is ignored for
a January or July
date. A January date would be resolved with
standard time, and a July
date with summer time, regardless of the `summer?'
value.
But in fact: (I'm running this on FreeBSD 3.4 and my
time zone is EST5EDT)
snowview:utils> scsh
Scsh 0.5.3
> (date->string (date (time (make-date 01 02 03 4 6
101))))
"Wed Jul 04 04:02:01 2001"
>
What's going on here is that `make-date' has defaulted
the `summer?' flag
to #F, so `time' builds a `struct tm' with 0 in its
`tm_isdst' slot (which
unambiguously means "Standard Time") and calls
`mktime'. So the date is
converted to a time as if it was specified in EST. I
don't actually see
any code in scsh that would implement the behavior
described in the
documentation I quoted above.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=110493&aid=440376&group_id=10493
|