Encode/decode-universal-time and DST

[Scott L. Burson]

On Mon, Nov 2, 2015 at 2:34 AM, Mark Evenson <evenson at 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