Can anyone explain the following? If I encode-universal-time a particular
date and then decode-universal-time the result shouldn't I end up with the
original input?
Allegro CL Lite gives:-
(decode-universal-time (encode-universal-time 1 0 0 20 10 1997))
1
0
23
19
10
1997
6
NIL
0
whereas Harlequin LWW gives the expected:-
CL-USER 7 > (decode-universal-time (encode-universal-time 1 0 0 20 10
1997))
1
0
0
20
10
1997
0
NIL
0
however, Allegro gives the expected answer for 19 11 1997:-
> (decode-universal-time (encode-universal-time 1 0 0 19 11 1997))
1
0
0
19
11
1997
2
NIL
0
If this is something to do with daylight saving shouldn't it work both
ways?
--
Ray Drew
CIA MediaSystems
London
·····@cia-group.com
Barry Margolin <······@bbnplanet.com> wrote in article
<··········@pasilla.bbnplanet.com>...
> It looks like Allegro is defaulting the timezone in ENCODE-UNIVERSAL-TIME
> to the zone that was in effect at the time you gave it, but
> DECODE-UNIVERSAL-TIME is using the current time zone. On 10/20/1997
> Daylight Savings Time was in effect, so 10/20/1997 0:00:01 CDT
corresponds
> to 10/19/1997 23:00:01 CST.
>
> The spec says that in E-U-T the timezone "defaults to the current
timezone
> adjusted for daylight savings time." Franz apparently interpreted this
to
> mean "adjusted for daylight savings time in effect at the specified
time."
> The description of D-U-T just says "defaults to the current timezone."
Your right, that's how CLTL2 defines it. CLHS has this for D-U-T:-
Returns the decoded time represented by the given universal time. If
time-zone is not supplied, it defaults to the current time zone adjusted
for daylight saving time. If time-zone is supplied, daylight saving time
information is ignored.
It looks like Allegro is currently conforming to CLTL2 in this respect and
LWW to the ANSI standard..
"Ray Drew" <·····@cia-group.com> writes:
> It looks like Allegro is currently conforming to CLTL2 in this respect and
> LWW to the ANSI standard..
I didn't look at your problem in detail here, but I note that there was an
X3J13 issue related to this, mentioned at the bottom of the page on
DECODE-UNIVERSAL-TIME's entry in CLHS: DECODE-UNIVERSAL-TIME-DAYLIGHT.