) (02/16/90)
the problem(s) folks have had with the RTC can all be fixed easily enough. first, reboot (m-c-m-c-abort) the machines which are time-servers. at the prompt following the self-tests, hit `E' for extended tests. this will, at some point, completely zero-out the battery-backup clock. when done, boot as normal, and fill in the correct time when it asks. you will need to adjust the namespace to correctly specify the time-zone and daylight-savings or whatever. this is probably what bill @ washington was having trouble with. I've seen it change an hour or two when the time-server responds to "Ask the time". also note: the battery only lasts about two weeks--it's not capable of long- term storage, so that if the machine is powered off for more than two weeks, the backup clock will have been zeroed already. -- clint
jwz@teak.berkeley.edu (Jamie Zawinski) (02/17/90)
Another "gotcha" to watch out for is the :TIMEZONE attribute of the namespace; this can have some evil interactions with daylight savings time. We used to have this set to the string "PST" (Pacific Standard Time). So what happened was, the time parser took this string, realized that it was daylight savings time, and turned it in to "PDT" (Pacific Daylight Time). So then when the conversion from TZ-string to TZ-number came, we got bumped to an earlier time zone (MST and PDT are the same at some level of abstraction...) I'm still not all that clear on where (or exactly what) the problem was, but it went away when we changed :TIMEZONE to be 8 instead of "PST". -- Jamie