Version: (using KDE 4.2.2) Installed from: SuSE RPMs The digital clock takes forever to react to a change in time. I.e., if I change the time using the date command at the console, the digital clock may show the wrong time for quite a while; my estimate is up to a minute. The same happens when waking up the computer from sleep/hibernate. For quite a while, the digital clock shows the time at which the computer was hibernated. I think a wait of maybe 1-2 seconds would be acceptable, but 30 seconds or more is not.
"takes forever" it takes between 0 and 60 seconds, less if you have "show seconds" in which case it's between 0 and 500 ms. i doubt you'd rather we wake up the cpu once a second (or more?) to check the time for the 99.9% of the time it's just fine so as to drain your battery better. being off for a minute seems like the lesser evil here. as for changing time, try doing it via the gui and the clock should update .. as for re-checking on restoring from hibernate/sleep, that looks to be a HAL (and then Solid) feature that needs implementing first. i'll let Kevin decide what to do with that ...
So it's 30 seconds on average. That's a long time when you are staring at the clock wondering what's going on. But apparently there are two separate issues: 1. Updating when the time is changed manually. I can accept the argument that that's a rare case and might not need to be addressed. However, it's weird when you change the clock on the console while looking at the clock in your panel, and the clock in the panel doesn't seem to notice that anything happened. Would waking up the clock every 3-5 seconds really be such a drain on power? I don't think it's necessary to wake up the clock every second or more often. 2. After hibernation/sleep. That's a much more frequent case. I encounter it at least once a day. The clock in my panel is my primary clock, and it happens all the time to me that I wake up my laptop and stare at the clock waiting for it to show the right time. I think this issue really needs to be solved. As for using the gui to change the time, I just wanted to point out that the digital clock applet itself does not provide an obvious way to change the time. That's where I would look when trying to set the time.
Sounds more like something which should be handled by powerdevil IMO. On the libsolid* side we shouldn't take care about what's going on in desktop apps. It's more up to powerdevil to "do something" (whatever it is) when resume is over.
This is, in my opinion, a more wide problem in which applications need to be notified of a resume for suspension. The most sane approach would be having a signal in PowerDevil's DBus interface (even better in the fd.o.PowerManagement one) ResumingFromSuspension(), to which applications (and I'm looking at the clock, amarok, kopete, etc) can attach. This was what PowerDevil was built for, after all, and that's the solution that looks the most sane to me. Opinions?
About issue no.1: bug 181380
I specify this bug on the suspend issue. Bug #181380 is for changing the system time. Concerning the suspend problem, I have a workaround in reviewboard: http://reviewboard.kde.org/r/5320
*** Bug 253399 has been marked as a duplicate of this bug. ***
Since 4.6, r1194833, there is now a signal on the DBus interface of KDE Power Management system which signals a resume event. Plasma can now use that for updating the clock. Reassigning to the clock applet.
SVN commit 1195347 by ruberg: BUG: 190311 Timeengine does now trigger an updated on all clocks on the new dbus resumedFromSuspend signal. Caution: You have to make sure to use the upower and not the hal-backend for this to work M +8 -0 timeengine.cpp M +1 -0 timeengine.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1195347