kherron@ms.uky.edu (Kenneth Herron) (11/13/90)
My machine (a 386-clone running AT&T sysv/386 3.2.1) handled the time change properly, but after a system reboot it was off by an hour. Probably this was due to blindly following the battery-backed clock. Is this something I have to live with (horrors!) or is there something wrong in my configuration? Kenneth Herron
rcd@ico.isc.com (Dick Dunn) (11/13/90)
kherron@ms.uky.edu (Kenneth Herron) writes: > My machine (a 386-clone running AT&T sysv/386 3.2.1) handled the > time change properly, but after a system reboot it was off by an > hour. Probably this was due to blindly following the battery-backed > clock. Right. When the system comes up, it sets the time off the battery clock. While it's running, it's got its own idea of correct time, maintained internally in the GMT 1970-based epoch we all know and love. As you make the jump through DST hyperspace, everything is fine...the internal GMT just keeps incrementing steadily along, and the time-conversion routines deal with the hiccup just as they should. But the battery clock time is a "wall clock" time, so it doesn't make the jump with you; you have to bash it twice a year the same way you run around and reset all your other clocks. Otherwise, you get time-warped on the next reboot. > Is this something I have to live with (horrors!) or is there something > wrong in my configuration? Nothing wrong with the configuration. I've often wished there were an option to keep the CMOS clock on GMT. Yeah, I know...that would make times look funny in DOS...but I don't use DOS, so I don't care. Seems a pity that the problem arises even tho UNIX is perfectly capable of dealing with the DST silliness. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 Cellular phones: more deadly than marijuana.
woods@eci386.uucp (Greg A. Woods) (11/14/90)
In article <1990Nov13.005923.24658@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: > kherron@ms.uky.edu (Kenneth Herron) writes: > > My machine (a 386-clone running AT&T sysv/386 3.2.1) handled the > > time change properly, but after a system reboot it was off by an > > hour. Probably this was due to blindly following the battery-backed > > clock. >[....] > Nothing wrong with the configuration. Well, I'd claim that the "vendor" forgot to put a line in crontab: 3 * * * * setclock At least one system I use does have this feature. Of course this method assumes the system clock is more correct, which is true if one has a network timed, or if one calls WWV regularly. > I've often wished there were an option to keep the CMOS clock on GMT. > Yeah, I know...that would make times look funny in DOS...but I don't use > DOS, so I don't care. Seems a pity that the problem arises even tho UNIX > is perfectly capable of dealing with the DST silliness. Yup, and that would be easier if the vendors of "PC" (i.e. iX86) UNIX would support a config option to let the system know you have a GMT hardware clock, not a wall-time one. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA
rwhite@nusdecs.uucp (0257014-Robert White(140)) (11/15/90)
In article <1990Nov13.005923.24658@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >I've often wished there were an option to keep the CMOS clock on GMT. >Yeah, I know...that would make times look funny in DOS...but I don't use >DOS, so I don't care. Seems a pity that the problem arises even tho UNIX >is perfectly capable of dealing with the DST silliness. Tisk tisk tisk, minus three points for not paying attention... To keep GMT in you CMOS clock but still get useful dates when you log in, do the following: file /etc/TIMEZONE: TZ=GMT export TZ file /etc/default/login (I think): TZ=(your favorite time zone here) When you log in you will have the correct "local" time used for all dating operations (file stat and such) but the system will use GMT for system-wide activities. You may want to reset TZ for cron in it's startup script to mke you life easier, but other than that this is a no-brainer. The system converts in and out of GMT anyway. The above just gets it to store the base time as GMT in the CMOS without worrying about it ever again. ******************************************************************* Robert White | Not some church, and not the state, Network Administrator | Not some dark capricious fate. National University | Who you are, and when you lose, crash!nusdecs!rwhite | Comes only from the things you chose. (619) 563-7140 (voice) | -- me. *******************************************************************
rcd@ico.isc.com (Dick Dunn) (11/16/90)
rwhite@nusdecs.uucp (0257014-Robert White(140)) writes: ...rcd@ico.isc.com (Dick Dunn) writes: > >I've often wished there were an option to keep the CMOS clock on GMT. > > [various babble] ... > Tisk tisk tisk, minus three points for not paying attention... > > To keep GMT in you CMOS clock but still get useful dates when > you log in, do the following: ...games with /etc/TIMEZONE, /etc/default/login, plus a note about cron... > ...You may want to reset TZ > for cron in it's startup script to mke you life easier, but other > than that this is a no-brainer... Yes, I know you can rig it, but... Oops, you lose one point; you didn't take care of remote login (which also doesn't go through /etc/default/login). It's not entirely a no-brainer, either (or else my state of no-brain-ness is at a lower level than yours:-), because I'd probably screw up every time I reset the clock by resetting it to local time instead of GMT. Natch, I don't reset the clock that often, only enough to compensate for drift (but then, that's exactly what would cause me to screw it up--I wouldn't do it often enough to remember). [Gripe digression: Whose &^%$#!! idea was it to use a 1.193182 MHz oscillator, anyway?!?!? If they'd chosen a sensible frequency on the AT, the 8254 could be programmed with a value that wouldn't drift noticeably.] Your suggestions are good, but I still wish there were a way to wire GMT into the CMOS clock handling without the timezone games. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 Cellular phones: more deadly than marijuana.