[armedbear] #443: ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument

[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