On Mon, Nov 2, 2015 at 2:34 AM, Mark Evenson evenson@panix.com wrote:
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.
Yes, exactly: it doesn't say this explicitly. (Sorry, I should have been clearer.) For 'decode-universal-time' it just says:
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. The daylight saving time flag is nil if time-zone is supplied.
For 'encode-universal-time' it's even more cryptic:
If _time-zone_ is supplied, no adjustment for daylight savings time is performed.
-- With no statement of what happens when the time zone _isn't_ supplied.
That's why I was at pains to show that the "time of the time" interpretation is the de facto standard -- and has been, all the way back to Zetalisp, at least.
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.
That would certainly be my recommendation :-)
Therefore, I would support moving to "time of the [time]" 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?
I have no idea what deployed software might exist, but I'll offer a plausibility argument that suggests that it's unlikely the change would break anything. "Time of the call" is useful only in a small interval around the current time; if you need accurate conversions of historical or future times, it's wrong. So I expect anyone doing historical time conversions with ABCL would have tripped over this previously and said something. (Though, if the application was developed from scratch on ABCL and the author hadn't worked with historical times on another CL, I suppose they might have thought this is just how it works.)
Anyone interested in this area should also be aware of the "local-time" package [0]. I'm not using it, but maybe I should be :-)
[0] https://common-lisp.net/project/local-time/
-- Scott