DECODE-UNIVERSAL-TIME-DAYLIGHTDECODE-UNIVERSAL-TIME does not say what happens with TIME-ZONE. Since the description of ENCODE-UNIVERSAL-TIME mentions that its behavior differs depending on whether a time zone is explicitly passed, some implementors may have assumed that DECODE-UNIVERSAL-TIME should do likewise.
Even if all implementations did the same thing, it should still be clarified whether an implementation were permitted to return dsp=NIL tz=n rather than dsp=T tz=n+1 for time zones in which daylight savings time was believed to be (or known to be) in effect. Currently, you cannot tell whether "NIL" for daylight-savings-time-p means "daylight savings time is in effect" or just "daylight savings time is not known to not be in effect".
These tools appear to be more portable than they are.
ENCODE-UNIVERSAL-TIME, DECODE-UNIVERSAL-TIME ignores daylight savings information if a timezone is explicitly specified.ENCODE-UNIVERSAL-TIME.;; ### This test case relies on time zone not changing in real ;; ### time, in defiance of warning in note at bottom ;; ### of p445.
(LET* ((HERE (NTH 8 (MULTIPLE-VALUE-LIST (GET-DECODED-TIME)))) ;Time zone (RECENTLY (GET-UNIVERSAL-TIME)) (A (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY)))) (B (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY HERE))))) (LIST A B (EQUAL A B)))
Under this proposal, this would return ((T 5) (NIL 5) NIL) in EDT, for example.
ENCODE-UNIVERSAL-TIME, DECODE-UNIVERSAL-TIME treats daylight savings information the same regardless of whether a time zone argument is explicitly or not. This seems actually to be what was intended originally.
This problem arose while trying to port Macsyma between different Common Lisp implementations. The cleanup committee does not have a strong opinion on this matter, as long as the behavior is specified.