GNOME Bugzilla – Bug 585668
Clock applet jumps in time when set to display seconds
Last modified: 2012-06-10 11:38:31 UTC
Please describe the problem: When set to include seconds in its time display, the panel clock sometimes misses a second, then remains longer on the next one, or first remains longer on one number, then misses the next one. This seems to happen with time set by a server as well as manually. Steps to reproduce: 1. Set clock to display seconds 2. Wait and observe 3. Be confused Actual results: Expected results: Does this happen every time? Yes Other information:
*** Bug 587064 has been marked as a duplicate of this bug. ***
so the bug is confirmed
I can confirm this too (Ubuntu 9.04/Gnome 2.26.1/Pentium III 700MHz), but it looks more like a tradeoff to me. Also: https://bugs.launchpad.net/gnome-panel/+bug/364089
I now run Debian 5.01/Gnome 2.22.3 and the seconds is bugging me no more. I tried to give the clock(gnome-panel) higher priority with the renice command but that changed nothing.
seems to work now on gnome 2.28
Ubuntu Karmic, Gnome 2.28.0. Still the same bug.
Same on Red Hat Enterprise Linux 5.5. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=581026
Created attachment 165300 [details] [review] One-line patch to fix the problem I fixed this by just changing timeouttime = (G_USEC_PER_SEC - tv.tv_usec)/1000+1; to timeouttime = (G_USEC_PER_SEC - tv.tv_usec)/1000+20; in clock.c. What I'm guessing was happening is it was waiting until one millisecond after the second changed, but the timer doesn't have that good a resolution, so sometimes (on some machines often, on some maybe never) it would try to update the clock a few milliseconds *before* the second changed over. Which wouldn't change anything. By waiting until 20 ms after the second changes, at least on my machine, it always gets there after the second has changed, and the second always ticks over correctly. This does mean that the clock is 19 ms later on average, but that's below human perception, and desktop clocks are often not so accurate anyway, so it should be fine. I could try with 10 instead of 20 if that would be more acceptable. An alternative approach would have been to check in update_clock() whether the clock was actually updated, and if not, wait 10 ms or so and try again. This would be more complicated to do, though, and would result in calling update_clock() more often. Note that I only tested this patch in Ubuntu Lucid Lynx, 10.04 LTS, which I think is GNOME 2.28.1. However, I looked over the changes to clock.c since then, and none seem relevant, so I'm assuming it will have the same effect there. Is there some particular place I should send the patch for it to get accepted, or is here okay? The HACKERS file is very outdated (suggests using CVS).
Another possibility would be to check if it's currently less than (say) 100 ms before the second rolls over, and if so, round up. Then the timeouttime can be selected to hit the next second exactly rather than 1 or 20 ms late, there's more tolerance for error (100 ms vs. 20 or whatever), and no extra calls to update_clock(). If it's preferred, I could write a patch that does that, too.
Bump? It's been over six months since I submitted the one-line patch in comment 8, and I've gotten no response. The patch is still good for current git, as far as I can tell. I tried to contact Vincent Untz a few times to no avail. Any suggestions on how I can get someone to look at the patch? I'm still seeing the bug, and it's very annoying.
This is typical of Gnome Devels. They often ignore annoyances that they don't think are important or are for older products that are being phased out. At least they make things work at a basic level, even if their cruft needs patching from time to time because they are lazy about fixing annoyances. It's very much unlike the KDE project, where they like things to be flashy and full of eye candy, but are full of bugs and get an arrogant attitude when one of us lowly users complains. Now what do I do? Should I download the source, apply the simple patch, build it all, and then install the homebrew version; or should I wait for gnome3 to make it to Debian testing repos and see if it is any better?
AFAICS GNOME 3.x doesn't have seconds resolution in the UI. I can see a dconf setting for it, but it doesn't seem to have any effect.
Comment on attachment 165300 [details] [review] One-line patch to fix the problem I've pushed this, but used 15 instead of 20. This should be fine as the resolution for timers is usually 10ms.
(In reply to comment #11) > This is typical of Gnome Devels. FWIW, this really doesn't help motivate developers. People sometimes have simply too many things to handle, and even small patches can be missed because of that :/
(In reply to comment #14) > FWIW, this really doesn't help motivate developers. People sometimes have > simply too many things to handle, and even small patches can be missed because > of that :/ FWIW, though, it also really doesn't help motivate people to submit patches in their spare time if they don't get developer attention for over a year even on a two-byte change. I did carefully follow all the instructions I found on the GNOME website and in the source code, contacted you multiple times by both IRC and e-mail, asked in #gnome on freenode, etc. Maybe you could update some of these places with more advice on how to reliably get developers' attention or something, because I sure did try in every way I could think of, for months, before giving up. Still, thanks for the commit, even if it was later than I expected.
Hi guys, I think this has regressed because in 12.04 or the patch isn't working because I am syncing my time with a stratum 2 router and when compared with system time is within .0000361 of a second of the ntp server. However the panel time is all over the place but generally up to 1 second behind the system time and the ntp router. I have also noticed this being logged in another bug https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/731570 That relates this bug back to 10.10 and we still have issues :(