LANE@SUMEX-AIM.STANFORD.EDU (Christopher Lane) (10/26/87)
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 -------
darrelj@SM.UNISYS.COM (10/26/87)
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.
koomen@CS.ROCHESTER.EDU (10/27/87)
Christopher, thanks for digging further. If it is true that Lisp "calls \CHECKDSTCHANGE with YDAY based on January 1 = 0" then instead of changing the math (GREATERP -> GEQ) it would perhaps be more appropriate for \NS.SETTIME to set \EndDST to SUB1 of whatever the network returns. And, indeed, changing \EndDST 305->304 instead of 305->298 does the trick as well. 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. So perhaps the problem lies in the interpretation of \EndDST. We might be dealing with a boundary case, in that this year the 305'th day is a Sunday. Does DST end on the [last Sunday <= \EndDST] or [last Sunday < \EndDST]? Curently the algorithm uses the former which gives the incorrect result. -- Hans
darrelj@sm.unisys.COM (10/27/87)
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.
DarrelAISupport.pasa@XEROX.COM (10/28/87)
We have received the following information from development on the workaround to the DST bug: You may have noticed the time is a little bit off this week. It turns out that Lisp has an off-by-one bug that strikes in non-leap years in which the month of the Daylight Savings Time change ends on a Saturday. We're fixing Lisp, but that's not much help for today. You can get your clock back on track by pretending that October is a day shorter (for you Lyric people, do this in an Interlisp exec): (SETQ \EndDST 304) (ADVISE '(\NS.SETTIME \PUP.SETTIME) 'AFTER '(SETQ \EndDST 304)) The ADVISE is necessary because the values Lisp gets from the time server include the DST variable. If you have a clock displayed on your screen, you may have to kick the clock process--bring up a PSW from the background menu, select the clock process, and click RESTART. This problem will go away on Nov 1, at which time the advice will no longer be necessary. I believe the only negative side-effect of the advice is that you will get the wrong DST indication if you inquire about dates in leap years in which October ends on a Sunday (but then, you already get the wrong answer for many years in the past in which DST did not occur, or occurred at different times of year, since Lisp treats all years like the present). (courtesy of Bill vanMelle)
vanMelle.pa@XEROX.COM.UUCP (10/28/87)
Sigh. As Darrel points out, there are indeed TWO off-by-one bugs: one that affects all date conversion (caused by the zero-based vs. one-based confusion), and one that only affects date parsing (the functions il:idate and cl:encode-universal-time, which incorrectly compute the day of the year after Feb 28 of a non-leap year). Thus, you need to back up \EndDST all the way to 303 to fix both (and \BeginDST when 1990 roles around). You care about date parsing mainly if you ever pass around file creation dates as a string sans time zone info. I trust we are all now thoroughly confused and can go back to real work :-) Bill
roberts@cognos.uucp (Robert Stanley) (11/01/87)
In article <8710261947.AA18742@rdcf.sm.unisys.com> darrelj@SM.UNISYS.COM writes: > 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. ... neat fix described ... >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. I am extremely pleased to see you mention DST *start*. When DST came on this year, we were faced with the fact that our two 1186's under KOTO misbehaved when the time was entered from the keyboard using (SETTIME). We reported this back to Xerox, but the problem quietly vanished a week later, before we (who were still novices on the system) had tracked it to its lair, or Xerox Canada had provided any feedback. At the University of Ottawa (assume I am posting from there - robs@uottawa) the two 1186 systems are not supported by servers of any kind, and essentially live in an isolated world of their own. This has led to a variety of interesting problems, particularly since we also have the 80 Mbyte disks. I guess I am interested to know if anyone else is running stand-alone (serverless) systems, or can suggest just how much resource on our Sun/3 UNIX machines the necessary serving software will consume. My experience with Sun networks to date is that even the most pessimistic predictions of storage requirements have proved to be woeful under-estimates, so I am looking for practical experience as opposed to manufacturers' recommendations. e-mail replies should be directed to roberts@cognos.uucp, which will actually reach me much faster than robs@uottawa.uucp, because the Xerox isn't on the mail system..... -- Robert Stanley Cognos Incorporated S-mail: P.O. Box 9707 Voice: (613) 738-1440 (Research: there are 2!) 3755 Riverside Drive FAX: (613) 738-0002 Compuserve: 76174,3024 Ottawa, Ontario uucp: decvax!utzoo!dciem!nrcaer!cognos!roberts CANADA K1G 3Z4
david@daisy.UUCP (David Schachter) (11/02/87)
A company I used to work for makes a radio-clock which eliminates most stupid DST problems. The clock receives WWV and WWVH time broadcasts from the U.S. National Bureau of Standards. The broad- casts give the time and the status of Daylight Savings Time, according to Federal law. (Local DST variations are not covered.) The clock makes these data available through an RS-232 port to the host system. If you are interested, send me mail or e-mail or give me a call. My mail address is: David Schachter 1962 Buchanan St. San Francisco, CA 94115-2818 My e-mail addresses are: well!davids or daisy!david My message machine phone number is: (415) 567-7663 Any my soul id is: (Purgatory) 32C-114-325-9-AGF [Reachable from all major after-lifes.]
SCHMIDT@SUMEX-AIM.STANFORD.EDU (Christopher Schmidt) (11/04/87)
[...] I guess I am interested to know if anyone else is running
stand-alone (serverless) systems, or can suggest just how much resource
on our Sun/3 UNIX machines the necessary serving software will consume.
My experience with Sun networks to date is that even the most
pessimistic predictions of storage requirements have proved to be woeful
under-estimates, so I am looking for practical experience as opposed
to manufacturers' recommendations. [...]
Storing a LOT of stuff on a Xerox server, we use about 80 Mbytes of
storage for several sysouts, lispusers, lisplibrary, on-line IRM,
fonts, and sources for one release of Xerox Lisp. Each additional
release takes about 31 megabytes. These are high estimates because we
have fonts for many types of printers, etc.. They do not include
user sysouts (the next biggest class of storage) or user files.
A Sun/3 is not a terribly good file server for d-machines because the
Xerox system tool doesn't speak TCP and the TCP FTP server doesn't
provide random access.
We've written an NFS client that runs under Lyric to provide random
access, but I wouldn't recommend it to anyone that is not expert both
in Xerox lisp and NFS details. Eg., it doesn't recover gracefully from
hardreset.
If you're still using Koto, be sure to use the version of TCP.DCOM
filed in [sumex-aim.stanford.edu]<lispusers.koto>. It's much faster
than the version released by Xerox ages ago. (The mods were folded
into the version released with Lyric, FYI.) I can send it electronically
if you don't have it already.
--Christopher
-------ralph@lasso.UUCP.UUCP (11/06/87)
Seeing this rash of messages concerning DST, I assume that the problem *only* concerns Lyric, though nothing forces this. Am I correct? If not, I've had *no* such problems under Koto-2 when we went off of DST. --Ralph
darrelj@SM.UNISYS.COM (Darrel VanBuer) (11/06/87)
The daylight savings time problem affects versions at least back to Intermezzo. The bug is however only apparent when the change happens on the earliest or latest possible date, and if you have DST parameters set by a (correctly) configured NS or PUP server (since the default initial value set in the Lisp sources is compatible with the code). Darrel