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."