ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument

[Mark Evenson]

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

[Mark Evenson]

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.

[Mark Evenson]

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.

[Mark Evenson]

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.