Encode/decode-universal-time and DST

[Mark Evenson]

On 2015/11/2 04:39, Scott L. Burson wrote:
> Hi,
> 
> As daylight-saving time ended in the US today, I discovered that ABCL's
> interpretation of the CL spec concerning the behavior of
> 'encode/decode-universal-time' around DST is not the usual one.
> 
> The usual interpretation is that when an explicit timezone is not supplied
> to these calls, DST is selected automatically based on whether it would
> have been in force (under certain assumptions, e.g., you're not in Arizona)
> at the time being converted.  ABCL's behavior is to convert the time based
> on whether DST is in force at the time of the call.

Are you referring to a specific section in the CLHS?  After (arguably a
minimal amount) of browsing, I couldn't find anything to indicate
whether one should consider the "time of the call" or the "time of the
time" for using daylight savings time in the CLHS.

> I think it's pretty clear that the former interpretation was the intended
> one, even if the language of the spec is admittedly not as clear as it
> should have been.  SBCL does it that way, CCL does it that way, and I even
> dug out the Genera 7.2 sources, which I still have lying around, to confirm
> that it did it that way too.
> 
> It looks like the ABCL interpretation was more-or-less intentional since a
> comment in the code says "adapted from SBCL".  Do the ABCL developers feel
> strongly that this is the correct behavior?

Many hands have worked for many years on the ABCL code base, so I don't
think we will get a "strong" belief either way from the developers.

In general, we developers (if I may be said to speak for the group) tend
to go the way of the majority of active, open source implementations in
the idea that we should provide the "least surprise" to our users.

Therefore, I would support moving to "time of the call" semantics for
implicit daylight savings time calculations in general.  My only worry
would be that we would mess up some sort of long running software that
depends on the previous behavior.  Does anyone know of any deployed
software using ABCL that would be tripped up by such a change?

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."