[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Universal Time Bugs



		   MACL (Version 1.3.2) Universal Time Bugs

[Note: This is our 2nd attempt to post this message and hence may be a
repeat.] 

Serious bugs have been discovered with MACL's versions of the 
Common Lisp universal time functions "encode-universal-time" and 
"decode-universal-time" in MACL.

1) Daylight savings time is handled incorrectly (either in encoding, 
decoding, or both).

2) Decode-universal-time does *not* appear to ignore daylight-
savings-time (DST) adjustments when the optional time-zone 
parameter is given (as advertised in Steele).

A manifestation of the first bug is:

    ? (multiple-value-list
        (decode-universal-time
         (encode-universal-time 0 0 0 1 4 1991))
    (0 0 23 31 3 1991 6 NIL 8)
    ?

Thus the decoding of the encoding of 12am 4/1/1991 is reported 
incorrectly as 11pm 3/31/1991.  Daylight savings is supposed to 
take effect on 4/7/1991.

A manifestation of the 2nd (& also first) bug is:

    ? (encode-universal-time 0 0 0 1 4 1991 8)
    2879481600
    ? (multiple-value-list (decode-universal-time 2879481600))
    (0 0 1 1 4 1991 0 T 8)     
    ? (multiple-value-list (decode-universal-time 2879481600 8))
    (0 0 1 1 4 1991 0 T 8)  

It has incorrectly assumed that DST is in effect on April 1 in both of 
the above decodings.  In the 2nd decoding, it *has* apparently 
adjusted for DST as the encoded time of 12am on 4/1 is returned as 
1am.

These function calls *do* work correctly in Sun Allegro CL 
(version 3.1.13.1).

This is really putting us in a bind as we need either for the UT 
functions to work correctly with DST, or for them to work correctly 
without it.  Neither of these conditions currently hold.

Have these problems been recognized before, and if so are there 
patches available?

Thanks much.

Chris Toomey, David Hinkle
Lockheed AI Center
toomey@neon.stanford.edu