The best I can remember was I had to reboot the server and go into CMOS to change the time.
This is really odd. All my SuSE boxes that were running adjusted to the time change without problems. The only one that didn't is my own workstation which was turned off. When it rebooted it got the "time correction of -3602 seconds exceeds sanity limits" error. Since it was obviously the same time change for all boxes this appears to be related to the fact it was turned off. Is this expected behavior? Can any ntp gurus out there enlighten me (use small words please, I'm on my 1st cup of coffee).
If you're sync'd to a NTP server, the change should occur automagically. This occured on my desktop system. I had to manually tell my notebook to connect to the server, at which point it adjusted itself to standard time.
That's what I would have expected. Here's the ntp log: 30 Oct 10:29:08 ntpd[3886]: synchronized to LOCAL(0), stratum 10 30 Oct 10:29:08 ntpd[3886]: kernel time sync disabled 0041 30 Oct 10:30:11 ntpd[3886]: kernel time sync enabled 0001 30 Oct 10:31:17 ntpd[3886]: synchronized to 192.168.1.4, stratum 2 30 Oct 10:50:52 ntpd[3886]: time reset -0.595142 s 30 Oct 10:55:07 ntpd[3886]: synchronized to LOCAL(0), stratum 10 30 Oct 10:57:16 ntpd[3886]: synchronized to 192.168.1.4, stratum 2 30 Oct 21:10:02 ntpd[3886]: ntpd exiting on signal 15 30 Oct 21:13:01 ntpd[3894]: ntpd exiting on signal 15 31 Oct 09:42:35 ntpd[3885]: synchronized to LOCAL(0), stratum 10 31 Oct 09:42:35 ntpd[3885]: kernel time sync disabled 0041 31 Oct 09:43:38 ntpd[3885]: kernel time sync enabled 0001 31 Oct 09:44:44 ntpd[3885]: synchronized to 192.168.1.4, stratum 2 31 Oct 09:46:58 ntpd[3885]: time correction of -3602 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. This may have something to do with the fact the system clock is set to local time (dual boot don't you know). It's no biggie, just kind of curious. Jeff