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.
When I discovered this, I went back to the manual and discovered that
`fill-in-date!' might be able to do the timezone defaulting I needed. But
the documentation for `fill-in-date!' correctly notes:
Oops: `fill-in-date!' isn't implemented yet.
Great.
So first off, I would like to report the apparent bug that `time' doesn't
behave as documented.
Secondly I would like to ask for some advice. I've got this log file full
of timestamped events. It was created by human beings who were looking at
a wall clock that is adjusted twice a year according to the EST5EDT rules.
I would like to convert those times into time values. Is there some
tasteful scsh code that will do what I want? `mktime' would do the job if
I could feed it a `struct tm' with a -1 in its `tm_isdst' -- but there
doesn't seem to be any way to get scsh to do that on my behalf...
- Alan
|