#443: ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument -------------------------+---------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: Component: interpreter | Version: Keywords: | Parent Tickets: -------------------------+---------------------- In <https://mailman.common-lisp.net/pipermail/armedbear- devel/2017-March/003807.html>
{{{ A contributor to the Maxima project bumped into this while trying Maxima + ABCL 1.4.0.
CL-USER(1): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -23) 3017516508 CL-USER(2): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -13) 3017516508 CL-USER(3): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 13) 3017516508 CL-USER(4): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 23) 3017516508 CL-USER(5): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 'foo) 3017516508
Not too surprising, I think -- a glance at ./src/org/armedbear/lisp/time.lisp shows that the TIME-ZONE argument doesn't take part in the calculations.
TIME-ZONE does come into play in pre-14840 versions of time.lisp and the results are consistent with other CL implementations, at least for the examples exercised by the Maxima test suite (date parsing). }}}
-- Ticket URL: http://abcl.org/trac/ticket/443 armedbear http://abcl.org armedbear
#443: ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument ------------------------------+----------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: assigned Priority: blocker | Milestone: 1.5.0 Component: interpreter | Version: 1.5.0-dev Resolution: | Keywords: Parent Tickets: | ------------------------------+----------------------- Changes (by mevenson):
* owner: => mevenson * priority: major => blocker * version: => 1.5.0-dev * status: new => assigned * milestone: => 1.5.0
Comment:
I bet you are running on a different JVM than Scott and I, something other than Java 8.
Look for errors in the *inferior-lisp* buffer.
I am in the process of consolidating time fixes for the next release.
-- Ticket URL: http://abcl.org/trac/ticket/443#comment:1 armedbear http://abcl.org armedbear
#443: ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument ------------------------------+----------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: assigned Priority: blocker | Milestone: 1.5.0 Component: interpreter | Version: 1.5.0-dev Resolution: | Keywords: Parent Tickets: | ------------------------------+----------------------- Description changed by mevenson:
Old description:
In https://mailman.common-lisp.net/pipermail/armedbear- devel/2017-March/003807.html
{{{ A contributor to the Maxima project bumped into this while trying Maxima + ABCL 1.4.0.
CL-USER(1): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -23) 3017516508 CL-USER(2): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -13) 3017516508 CL-USER(3): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 13) 3017516508 CL-USER(4): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 23) 3017516508 CL-USER(5): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 'foo) 3017516508
Not too surprising, I think -- a glance at ./src/org/armedbear/lisp/time.lisp shows that the TIME-ZONE argument doesn't take part in the calculations.
TIME-ZONE does come into play in pre-14840 versions of time.lisp and the results are consistent with other CL implementations, at least for the examples exercised by the Maxima test suite (date parsing). }}}
New description:
In <https://mailman.common-lisp.net/pipermail/armedbear- devel/2017-March/003807.html>
{{{ A contributor to the Maxima project bumped into this while trying Maxima + ABCL 1.4.0.
CL-USER(1): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -23) 3017516508 CL-USER(2): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -13) 3017516508 CL-USER(3): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 13) 3017516508 CL-USER(4): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 23) 3017516508 CL-USER(5): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 'foo) 3017516508
Not too surprising, I think -- a glance at ./src/org/armedbear/lisp/time.lisp shows that the TIME-ZONE argument doesn't take part in the calculations.
TIME-ZONE does come into play in pre-r14840 versions of time.lisp and the results are consistent with other CL implementations, at least for the examples exercised by the Maxima test suite (date parsing). }}}
--
-- Ticket URL: http://abcl.org/trac/ticket/443#comment:2 armedbear http://abcl.org armedbear
#443: ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument ------------------------------+----------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: assigned Priority: blocker | Milestone: 1.5.0 Component: interpreter | Version: 1.5.0-dev Resolution: | Keywords: Parent Tickets: | ------------------------------+----------------------- Description changed by mevenson:
Old description:
In https://mailman.common-lisp.net/pipermail/armedbear- devel/2017-March/003807.html
{{{ A contributor to the Maxima project bumped into this while trying Maxima + ABCL 1.4.0.
CL-USER(1): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -23) 3017516508 CL-USER(2): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -13) 3017516508 CL-USER(3): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 13) 3017516508 CL-USER(4): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 23) 3017516508 CL-USER(5): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 'foo) 3017516508
Not too surprising, I think -- a glance at ./src/org/armedbear/lisp/time.lisp shows that the TIME-ZONE argument doesn't take part in the calculations.
TIME-ZONE does come into play in pre-r14840 versions of time.lisp and the results are consistent with other CL implementations, at least for the examples exercised by the Maxima test suite (date parsing). }}}
New description:
In <https://mailman.common-lisp.net/pipermail/armedbear- devel/2017-March/003807.html>.
Breaks with r14840.
{{{ A contributor to the Maxima project bumped into this while trying Maxima + ABCL 1.4.0.
CL-USER(1): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -23) 3017516508 CL-USER(2): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -13) 3017516508 CL-USER(3): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 13) 3017516508 CL-USER(4): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 23) 3017516508 CL-USER(5): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 'foo) 3017516508
Not too surprising, I think -- a glance at ./src/org/armedbear/lisp/time.lisp shows that the TIME-ZONE argument doesn't take part in the calculations.
TIME-ZONE does come into play in pre-14840 versions of time.lisp and the results are consistent with other CL implementations, at least for the examples exercised by the Maxima test suite (date parsing). }}}
--
-- Ticket URL: http://abcl.org/trac/ticket/443#comment:3 armedbear http://abcl.org armedbear
#443: ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument ------------------------------+----------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: accepted Priority: blocker | Milestone: 1.5.0 Component: interpreter | Version: 1.5.0-dev Resolution: | Keywords: Parent Tickets: | ------------------------------+----------------------- Changes (by mevenson):
* status: assigned => accepted
-- Ticket URL: http://abcl.org/trac/ticket/443#comment:4 armedbear http://abcl.org armedbear
#443: ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument ------------------------------+----------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: accepted Priority: blocker | Milestone: 1.5.0 Component: interpreter | Version: 1.5.0-dev Resolution: | Keywords: Parent Tickets: | ------------------------------+-----------------------
Comment (by mevenson):
Applied Robert Dodier's patch from working through the Maxima problems http://abcl.org/trac/changeset/14995 which seems to improve behavior. ANSI tests are still failing, so keeping this ticket open until I get a better idea of why.
-- Ticket URL: http://abcl.org/trac/ticket/443#comment:5 armedbear http://abcl.org armedbear
#443: ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument ------------------------------+----------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: closed Priority: blocker | Milestone: 1.5.0 Component: interpreter | Version: 1.5.0-dev Resolution: fixed | Keywords: Parent Tickets: | ------------------------------+----------------------- Changes (by mevenson):
* status: accepted => closed * resolution: => fixed
Comment:
Resolved with r14996 and r14997.
As pointed out in <https://mailman.common-lisp.net/pipermail/armedbear- devel/2017-April/003823.html>, the original patch from Scott Burson was incorrectly applied. After reapplying the original patch (and thereby removing Robert Dodier's changes), things seem much better in that the implementation now no longer ignores the time zone argument to ENCODE-UNIVERSAL-TIME and the ANSI test regressions have disappeared.
-- Ticket URL: http://abcl.org/trac/ticket/443#comment:6 armedbear http://abcl.org armedbear
armedbear-ticket@common-lisp.net
-
armedbear