Bugzilla – Bug 119831
Changing local date / time through yast and click apply, gnome-screensaver starts
Last modified: 2006-01-30 14:24:34 UTC
Steps to reproduce: 1. In clock applet right click and select 'Adjust Date & Time' 2. Type root password when prompted (I tried these steps as a normal user) 3. In Time and Date field, click 'Change' button 4. In 'Change System Date and Time' dialog, change either date or time and click apply. (I changed both) Actual result: Screen become blank. Thought of pressing control + alt + backspace, when pressing control key, gnome-screensaver poped me for password. Expected result: There is no relation between changing time and screen saver (according to the end user), so screen saver should not prompt. How often: Always
There is definitely a relation - the screensaver waits for the user to be idle an amount of time.
JPR: I have set screen saver timeout as 30 minutes. Immediately after clicking 'Apply' in the Yast window, screen goes blank and when you move the mouse or press any key, gnome-screen saver will popup for password.
Yes - because it looks at the last time it new about, say "1pm" and then the new time, say "3pm", and when the code checks it sees 2 hours of idle and blanks the screen. Setting the clock back might make the user wait longer than expect however. Please check this out rodrigo out.
(In reply to comment #3) > Yes - because it looks at the last time it new about, say "1pm" and then the > new time, say "3pm", and when the code checks it sees 2 hours of idle and > blanks the screen. > > Setting the clock back might make the user wait longer than expect however. > I think AN is right because AN said that from the point of view of the user, there is no relation between changing the system time and triggering the screen saver. What you're explaining is the relation that exists in the screen saver triggering algorithm.
Unfortunately, the timeout code in glib, which is what is used in gnome-screensaver, uses the system time to trigger the timeouts, so I don't see an easy fix for this.
*** Bug 144499 has been marked as a duplicate of this bug. ***
As far as I understand, the YaST module actually changes the CMOS clock of the system and re-reads it then. Thus the "offset" of the whole system changes instantly. I'm closing this in agreement with Dell, as it's a behaviour by design.