Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!ucbvax!SM.UNISYS.COM!darrelj From: darrelj@SM.UNISYS.COM Newsgroups: comp.sys.xerox Subject: Re: End of DST Message-ID: <8710261947.AA18742@rdcf.sm.unisys.com> Date: Mon, 26-Oct-87 14:43:00 EST Article-I.D.: rdcf.8710261947.AA18742 Posted: Mon Oct 26 14:43:00 1987 Date-Received: Wed, 28-Oct-87 19:41:29 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 55 Date: Mon, 26 Oct 87 09:27:08 PST From: Christopher Lane Subject: End of DST To: Info-1100@SUMEX-AIM.STANFORD.EDU Message-Id: <12345600160.25.LANE@SUMEX-AIM.STANFORD.EDU> Since the end of Daylight Savings Time, Lisp's time is off by an hour. Since all the other hosts on our net (including Xerox servers and machines running Mesa (check your SystemTool time)) have the correct time, I assume it is a bug in the algorithm that monitors DST changes. The fix of (SETQ \EndDST 298) is not acceptable since 305 is still the proper value and the fix fails as soon as the workstation goes to the net for the time and gets a new value of \EndDST after logout. I tracked through the code that does this determination (I had to use Koto sources as we've not received Lyric sources from the UGP yet; I assume for the function in question is identical for Lyric) and I believe the trouble is in the last COND clause in \CHECKDSTCHANGE. I'm not 100% positive (I had a hard time working through this) but my guess is that the problem stems from the fact that \EndDST as supplied by the network, 305, is based on numbering the year with January 1 = 1 (Time Protocol, XSIS 088404) whereas lisp calls \CHECKDSTCHANGE with a YDAY based on January 1 = 0 and I believe that this is not properly reflected in the math that follows. Regardless, I made a new version of the function where I changed an IGREATERP to a GEQ and things seem to be working now. Even if the fix is faulty, another clause of the function will kick in a week anyway and fix the problem. The patched version of the function is filed in ENDDSTPATCH.DCOM on and in ENDDSTPATCH.LCOM on , both on SUMEX-AIM.Stanford.EDU . If anyone follows up on this, I'd be curious to know what the real story is. - Christopher ------- The safest single change to \CHECKDSTCHANGE would be to add a first line (SETQ DSTDAY(DIFFERENCE DSTDAY 1)), since changing a single comparison will likely introduce an off-by one error when DST changes at the other extreme (this month, the change was on the earliest possible date). The fix should also set \BeginDST to 98 and \EndDST to 305 for standalone users, since the IOCHAR file also initialized them for zero origin. [The alternative is to fix all of \NS.SETTIME, \PUP.SETTIME (Alto time standard uses same values as NS), and the Lisp based time servers in the library/users packages. After the end of this month, the next time DST algorithms could err under present rules is 1 Apr 1990, when we will have the earliest possible start of DST, and then 7 Apr 1991 when we will have the latest possible start of DST.