This is, for the most part, just a curiosity. I've noticed that changing the system date setting through either the panel applet in the KDE, or through an xterm makes my monitor go into standby. It comes back if I click the mouse (and I will assume other HID events would produce the same behavior.) Can anybody explain why this happens? Steven
Steven T. Hatton wrote:
This is, for the most part, just a curiosity. I've noticed that changing the system date setting through either the panel applet in the KDE, or through an xterm makes my monitor go into standby. It comes back if I click the mouse (and I will assume other HID events would produce the same behavior.) Can anybody explain why this happens?
Steven
Guess the time difference between the original time and the new time is bigger than time configured for the monitor to go into powersaving mode. But could be other reason. Anyway, it is best to use xntp to take care of changing system time. It makes the adjustments in small steps that otherwise could upset some programs. That works of course only if you are connected to the internet. Ulf
On Saturday 05 November 2005 06:19 pm, Ulf Rasch wrote:
Guess the time difference between the original time and the new time is bigger than time configured for the monitor to go into powersaving mode. But could be other reason. Anyway, it is best to use xntp to take care of changing system time. It makes the adjustments in small steps that otherwise could upset some programs. That works of course only if you are connected to the internet.
Ulf
Actually, the way I discovered this involves xntp. I normally use xntp, but when I decided to strip my system to the bare minimum and rebuild the SuSE 10 installation, I neglected to reinstall xntp. I noticed it was getting dark fairly early, and reasoned that I had not be telaproted north of the artcic circle, nor had the Earth undergone a pole shift. It therefore followed that my clock must be wrong. When I installed xntp, that's when I noticed the behavior. I have an internal server set up so that I /can/ get updates without hitting the internet. That insures that my systems are internally synchronized, but I still need a connection to get the ntp server synched up with the rest of the world. Steven
On Saturday 05 November 2005 20:28, Steven T. Hatton wrote:
On Saturday 05 November 2005 06:19 pm, Ulf Rasch wrote:
[...] Anyway, it is best to use xntp to take care of changing system time. It makes the adjustments in small steps that otherwise could upset some programs. That works of course only if you are connected to the internet.
Actually, the way I discovered this involves xntp. I normally use xntp, but when I decided to strip my system to the bare minimum and rebuild the SuSE 10 installation, I neglected to reinstall xntp. I noticed it was getting dark fairly early, and reasoned that I had not be telaproted north of the artcic circle, nor had the Earth undergone a pole shift. It therefore followed that my clock must be wrong. When I installed xntp, that's when I noticed the behavior. I have an internal server set up so that I /can/ get updates without hitting the internet. That insures that my systems are internally synchronized, but I still need a connection to get the ntp server synched up with the rest of the world.
My home ntpd server refused to accept the time update from the *.us.pool.ntp.org server pool, reporting this nastygram in the ntp log: "time correction of -3599 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time." The system's reported time was about an hour off due to the clock change last week and the fact that the server was down on that day (lack of electricity due to a recent hurricane), so the automatic change never occurred on the server. After manually poking the generally correct time into the computer and restarting the ntpd server, then it sync'd and adjusted its time correctly.
On Sunday 06 November 2005 03:00, Synthetic Cartoonz wrote:
My home ntpd server refused to accept the time update from the *.us.pool.ntp.org server pool, reporting this nastygram in the ntp log: "time correction of -3599 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time." The system's reported time was about an hour off due to the clock change last week and the fact that the server was down on that day (lack of electricity due to a recent hurricane), so the automatic change never occurred on the server.
The reason for this is that you have your CMOS clock set to local time. If you had it set to UTC there wouldn't have been a problem In general, the hardware clock should always be set to UTC, it just makes everything else so much easier.
participants (4)
-
Anders Johansson
-
Steven T. Hatton
-
Synthetic Cartoonz
-
Ulf Rasch