Opened 2 years ago

Closed 2 years ago

#443 closed defect (fixed)

ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument

Reported by: mevenson Owned by: mevenson
Priority: blocker Milestone: 1.5.0
Component: interpreter Version: 1.5.0-dev
Keywords: Cc:
Parent Tickets:

Description (last modified by mevenson)

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

Subtickets

Change History (6)

comment:1 Changed 2 years ago by mevenson

  • Milestone set to 1.5.0
  • Owner set to mevenson
  • Priority changed from major to blocker
  • Status changed from new to assigned
  • Version set to 1.5.0-dev

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.

comment:2 Changed 2 years ago by mevenson

  • Description modified (diff)

comment:3 Changed 2 years ago by mevenson

  • Description modified (diff)

comment:4 Changed 2 years ago by mevenson

  • Status changed from assigned to accepted

comment:5 Changed 2 years ago 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.

comment:6 Changed 2 years ago by mevenson

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

Note: See TracTickets for help on using tickets.