https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c41 --- Comment #41 from jorge aires <jorge.adriano@gmail.com> 2012-11-05 17:01:04 UTC --- (In reply to comment #40)
(In reply to comment #38)
Without a running ntpd the system time will not be written back and indeed this is intended.
Well then the question becomes, shouldn't ntpd be running and why isn't it. What I am asking really is, in a properly installed desktop system, should changes to the system time done via KDE's clock settings (or using date, or using ntpdate) be lost after reboot? It really doesn't seem to me like the proper behaviour should require for the user to manually change the hardware clock time, either using hwclock --systohc, or by accessing the BIOS. Yet any change to the system clock, not just small changes of a few minutes but also big changes of a few hours, are not preserved after reboot. The system time after reboot always coincides with the hwclock. And given that, when there are any DST changes, what happens is also precisely that the system time does change to reflect them, and then upon reboot again it coincides with the hwclock, I'm inclined to believe this is a manifestation of the same problem.
Only if a ntpd daemon runs for a longer time then kernel is switched in the so called elven minute mode (compare manual page adjtimex(2)) which then writes the system time back to the hardware clock in real time accuracy. Only if the hardware clock if off by more then 900 seconds (15 minutes) this is not done even in the eleven minutes mode as there are timezone with 30 minutes offset.
-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.