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.
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?
-- Scott
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?
On 2015/11/2 11:34, Mark Evenson wrote: […]
Therefore, I would support moving to "time of the call" semantics for
err "support moving from 'time of the call' to 'time of the time'"
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?
On 2015-11-02, Mark Evenson evenson@panix.com wrote:
err "support moving from 'time of the call' to 'time of the time'"
I'm in favor of that -- FWIW.
Thanks again to the developers for their efforts.
best,
Robert Dodier
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
On 2015/11/2 19:26, Scott L. Burson wrote:
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.
[…]
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 :-)
[…]
Filed as ticket [403][] to track implementation.
[403]: http://abcl.org/trac/ticket/403
On 11/2/15 19:26, Scott L. Burson wrote:
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.
[…]
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 :-)
[…]
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
Any argument about just using local-time from ABCL? Setting the special *use-political-time* seems to be all that is needed. I would throw local-time into ABCL-CONTRIB if the licensing can be shown to be compatible.
On 2015-11-07, Mark Evenson evenson@panix.com wrote:
Any argument about just using local-time from ABCL? Setting the special *use-political-time* seems to be all that is needed. I would throw local-time into ABCL-CONTRIB if the licensing can be shown to be compatible.
Sounds OK to me -- for what it's worth.
Best,
Robert Dodier
Using local-time is not a bad idea, but I worked up a patch for the existing code anyway. Attached.
I tried to run the test suite, as requested on the Contributing page, but it's looking for '../ansi-test/rt-package.lsp' which I don't have, and don't see in the repo.
-- Scott
On Sat, Nov 7, 2015 at 7:20 AM, Mark Evenson evenson@panix.com wrote:
On 11/2/15 19:26, Scott L. Burson wrote:
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.
[…]
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 :-)
[…]
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
Any argument about just using local-time from ABCL? Setting the special *use-political-time* seems to be all that is needed. I would throw local-time into ABCL-CONTRIB if the licensing can be shown to be compatible.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Oops -- didn't realize I needed to add an autoload. Updated patch attached.
(Is email the way you like to receive patches?)
-- Scott
On Sun, Nov 8, 2015 at 5:44 PM, Scott L. Burson Scott@sympoiesis.com wrote:
Using local-time is not a bad idea, but I worked up a patch for the existing code anyway. Attached.
I tried to run the test suite, as requested on the Contributing page, but it's looking for '../ansi-test/rt-package.lsp' which I don't have, and don't see in the repo.
-- Scott
On Sat, Nov 7, 2015 at 7:20 AM, Mark Evenson evenson@panix.com wrote:
On 11/2/15 19:26, Scott L. Burson wrote:
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.
[…]
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 :-)
[…]
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
Any argument about just using local-time from ABCL? Setting the special *use-political-time* seems to be all that is needed. I would throw local-time into ABCL-CONTRIB if the licensing can be shown to be compatible.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Thanks for the patch!
Adding docstrings and so forth before committing SYS:GET-TIME-ZONE as an official interface. Probably adding an exported symbol in the EXTENSIONS package as well.
local-time will currently *not* be included in stock ABCL-CONTRIB.
On 09 Nov 2015, at 03:03, Scott L. Burson Scott@sympoiesis.com wrote:
Oops -- didn't realize I needed to add an autoload. Updated patch attached.
(Is email the way you like to receive patches?)
Email is fine for now, and everything submitted as such is reviewed (at least by me). We’re looking at adding a bridge to the common-lisp.net gitlab in the near future.
On Sun, Nov 8, 2015 at 5:44 PM, Scott L. Burson Scott@sympoiesis.com wrote:
Using local-time is not a bad idea, but I worked up a patch for the existing code anyway. Attached.
I tried to run the test suite, as requested on the Contributing page, but it's looking for '../ansi-test/rt-package.lsp' which I don't have, and don't see in the repo.
You need to clone [ANSI-TEST][] as sibling of the directory where the ‘abcl.asd’ definition is rooted in the local filesystem. In the future, we should provide a restart that will “git clone” it for you if you wish. In the future, ANSI-TEST may be moved to an asdf description which would allow location and installation via Quicklisp (q.v.).
[ansi-test]: https://gitlab.common-lisp.net/groups/ansi-test
-- Scott
On Sat, Nov 7, 2015 at 7:20 AM, Mark Evenson evenson@panix.com wrote:
On 11/2/15 19:26, Scott L. Burson wrote:
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.
[…]
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. […]
On 09 Nov 2015, at 09:55, Mark Evenson evenson@panix.com wrote:
Thanks for the patch!
Added as [svn][r14840]; please test!
[r14840]: http://abcl.org/trac/changeset/14840
armedbear-devel@common-lisp.net
-
Mark Evenson -
Robert Dodier -
Scott L. Burson