Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!sm.unisys.COM!darrelj
From: darrelj@sm.unisys.COM
Newsgroups: comp.sys.xerox
Subject: Re: End of DST
Message-ID: <8710271856.AA02173@rdcf.sm.unisys.com>
Date: Tue, 27-Oct-87 13:56:00 EST
Article-I.D.: rdcf.8710271856.AA02173
Posted: Tue Oct 27 13:56:00 1987
Date-Received: Fri, 30-Oct-87 02:29:07 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 36


   To: Christopher Lane <LANE@SUMEX-AIM.STANFORD.EDU>
   Cc: Info-1100@SUMEX-AIM.STANFORD.EDU
   Subject: Re: End of DST 
   In-Reply-To: Your message of Mon, 26 Oct 87 09:27:08 -0800.
                <12345600160.25.LANE@SUMEX-AIM.STANFORD.EDU> 
   Date: Mon, 26 Oct 87 14:45:08 -0500
   From: koomen@cs.rochester.edu

   If it is true that Lisp "calls \CHECKDSTCHANGE with YDAY based on
   January 1 = 0" ...   Curiously, as far as I can tell the above
assumption is incorrect.
   Today, Oct 26, is the 299th day of the year, and tracing \CHECKDSTCHANGE
   shows it is called with 299, not 298.


   -- Hans

The missing detail in understanding the DST parameters is that all
players in the Xerox world compute day of year as though every year
had 29 days in February, so the 299 to \CHECKDSTCHANGE is the 300th
day in zero origin numbering for a leap year.  Let's hope the tester
at Xerox includes tests like (GDATE 668936752 '(DATEFORMAT TIME.ZONE))
and gets 1-Apr-90 04:00:00 PDT  (NOT 3AM PST).

In checking this out, I discovered that there is still another date
bug, in that (GDATE (IDATE "1-APR-90 03:00")'(DATEFORMAT TIME.ZONE))
gives "1-Apr-90 04:00:00 PDT", while (GDATE (IDATE "8-APR-90
03:00")'(DATEFORMAT TIME.ZONE)) gives "8-Apr-90 03:00:00 PDT", so it
looks like \PACKDATE also has a (different boundary condition error
(caused by overlooking the convention that all years are leap years in
athe call to \ISDST?).
In another 50 years the whole date mechanism is going to disintegrate
when the seconds clock ticks past 2^31.

	Darrel