🚀 go-pugleaf

   Date: Mon, 26 Oct 87 09:27:08 PST
   From: Christopher Lane <LANE@SUMEX-AIM.STANFORD.EDU>
   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
   <LISPUSERS.KOTO> and in ENDDSTPATCH.LCOM on <LISPUSERS.LYRIC>, 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.