Subject: encode-universal-time bug in clisp-1998-09-09?

From: Russell Senior <[email-masked]>
Date: 20 Oct 1998 12:56:48 -0700

$ uname -a
Linux coulee.tdb.com 2.1.115 #5 SMP Wed Sep 30 17:06:15 PDT 1998 i686
unknown

This is a Debian 2.0 box and I am in the Pacific Timezone (ie,
westcoast of US, TZ=PST8PDT).  I compiled CLISP from source.

> (lisp-implementation-version) 
"1998-09-09 (September 1998)"
> (decode-universal-time (encode-universal-time 0 0 0 1 1 1970))
0 ;
0 ;
23 ;
31 ;
12 ;
1969 ;
2 ;
NIL ;
8
> (decode-universal-time (encode-universal-time 0 0 0 1 1 1970 8))
0 ;
0 ;
0 ;
1 ;
1 ;
1970 ;
3 ;
NIL ;
8

It looks like the problem is in sys::default-time-zone, which is
defined in src/time.d.  My German isn't so good, so I haven't yet
figured out what `UTstunde' is.

> (sys::default-time-zone)
7 ;
T

Shouldn't I be getting an 8?

Thanks in advance!

-- 
Russell Senior
[email-masked]

---

From: Bruno Haible <[email-masked]>
Date: Tue, 20 Oct 1998 23:15:32 +0200 (MET DST)

> > (decode-universal-time (encode-universal-time 0 0 0 1 1 1970 8))

This one is correct. encode-universal-time interprets the date you give
as 1970-01-01, 08:00:00 GMT and then converts it to your local time zone.

> > (decode-universal-time (encode-universal-time 0 0 0 1 1 1970))

This is not correct; it works for the day after or the year 1971, however.
clisp tried to determine whether there was DST in your timezone at that
date, issued two C library calls in order to determine this, and thus
got trapped in the limitation that the C type `time_t' under Unix doesn't
support dates before 1970-01-01.

> defined in src/time.d.

Yes, the code in that function tries to guess the time zone and DST value.
For dates before 1970 it falls back to the current date. Since we are now
(still) in DST, it starts interpreting the value in DST.

> Shouldn't I be getting an 8?

This is an undocumented function. The first value happens to be the time zone
with DST correction already included. 7 is correct in your case.

So, clisp does have a year 1970 problem, but it does not have a year 2000
problem :-)

Bruno

---

From: Russell Senior <[email-masked]>
Date: 21 Oct 1998 00:45:34 -0700

>>>>> "Russell" == Russell Senior <[email-masked]> writes:

Russell> $ uname -a Linux coulee.tdb.com 2.1.115 #5 SMP Wed Sep 30
Russell> 17:06:15 PDT 1998 i686 unknown

Russell> This is a Debian 2.0 box and I am in the Pacific Timezone
Russell> (ie, westcoast of US, TZ=PST8PDT).  I compiled CLISP from
Russell> source.

   > (decode-universal-time (encode-universal-time 0 0 0 1 1 1970))
   0 ; 0 ; 23 ; 31 ; 12 ; 1969 ; 2 ; NIL ; 8
   > (decode-universal-time (encode-universal-time 0 0 0 1 1 1970 8))
   0 ; 0 ; 0 ; 1 ; 1 ; 1970 ; 3 ; NIL ; 8

Russell> It looks like the problem is in sys::default-time-zone, which
Russell> is defined in src/time.d.  My German isn't so good, so I
Russell> haven't yet figured out what `UTstunde' is.

   > (sys::default-time-zone)
   7 ; T

Russell> Shouldn't I be getting an 8?

The problem appears to be with the domain of (sys::default-time-zone)
under UNIX and WIN32.  On those platforms, the timezone is computed
using the C library calls localtime() and gmtime().  Consequently, the
valid inputs are limited to valid Unix calendar times (> Jan 1, 1970).
If the input time is outside that range, the default-time-zone is
whatever the timezone is currently.  Today, here, that is daylight
savings, which was unexpected for the date I tested.

Seems like this could be more robust, perhaps falling back to the code
in src/timezone.lsp?

BTW, the altavista babelfish at:

   <http://babelfish.altavista.com/cgi-bin/translate?>

though far from perfect, was useful in translating some of the
comments/variable names. :-)

-- 
Russell Senior
[email-masked]

---

From: Sam Steingold <[email-masked]>
Date: 21 Oct 1998 09:41:21 -0400

>>>> In message <[email-masked]>
>>>> On the subject of "Re: encode-universal-time bug in clisp-1998-09-09?"
>>>> Sent on Wed, 21 Oct 1998 00:00:23 -0700 (PDT)
>>>> Honorable Bruno Haible <[email-masked]> writes:
 >> 

Shouldn't it fall back to the same date in the current year?
(like, judging DST on 1969-1-1 by 1998-1-1, not by 1998-10-21)

-- 
Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
When we break the law, they fine us, when we comply, they tax us.

---

From: Bruno Haible <[email-masked]>
Date: Fri, 23 Oct 1998 20:51:18 +0200 (MET DST)

> Seems like this could be more robust, perhaps falling back to the code

I just made the code more robust, thus fixing bug you mentioned in the
development sources. Thanks for the suggestion.

Bruno

! To unsubscribe from the clisp-list mailing list, send mail to     !
!                    [email-masked]                        !
! including the two words "unsubscribe clisp-list" as message body. !