After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 604317 - Clock applet shows slightly wrong time
Clock applet shows slightly wrong time
Product: gnome-panel
Classification: Other
Component: clock
Other Linux
: Normal normal
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Reported: 2009-12-10 22:55 UTC by Andrey Vihrov
Modified: 2011-05-23 23:09 UTC
See Also:
GNOME target: ---
GNOME version: ---

Proposed fix (868 bytes, patch)
2009-12-10 22:55 UTC, Andrey Vihrov
committed Details | Review

Description Andrey Vihrov 2009-12-10 22:55:45 UTC
Created attachment 149552 [details] [review]
Proposed fix

If the Clock applet is not displaying seconds, it will switch the minutes number somewhat ~30 seconds after it should have. This is due to inaccurate estimation of remaining seconds in current minute in applets/clock/clock.c. Attaching a patch that fixes the issue.
Comment 1 Andrey Vihrov 2009-12-20 08:47:57 UTC
After digging more, I found out that the delay is exactly 36 seconds. Considering that exactly 24 leap seconds have been inserted since 1970, I concluded (36 + 24 = 60) that this is the cause. Indeed, my system's clock accounts for leap seconds. If the timezone is switched back to ignoring leap seconds, the problem no longer exists: 'date' reports exactly the time displayed by the Clock applet.

Since leap seconds are not in POSIX time, the validity of this bug report becomes questionable.

Comment 2 Vincent Untz 2010-01-14 00:46:59 UTC
Hrm, I'm not sure why the behavior of the clock applet and of date would be different, though. Do you have any idea what's the difference there?
Comment 3 Vincent Untz 2010-01-14 00:47:17 UTC
Comment on attachment 149552 [details] [review]
Proposed fix

Based on your analysis, I believe this patch is not the right way to handle things.
Comment 4 Andrey Vihrov 2010-01-14 08:18:48 UTC
(In reply to comment #2)

Let the real number of seconds passed since January 1, 1970 be R, and the number of leap seconds be L. Then POSIX time, P, is equal to (R - L) [1]. Currently the applet computes seconds remaining in this minute as P % 60 = (R - L) % 60, which is correct.
Now change the timezone to non-POSIX which does not ignore leap seconds (as I had; on my installation the data is in /usr/share/zoneinfo/right). P, which is reported by time(), becomes R. The applet now computes R % 60. So the sleep intervals get shifted by L % 60 seconds. The 'date' program uses localtime() instead (which can be verified in the source), which seems to break down time correctly in this case, too. Thus 'date' and the applet now have a L % 60 second difference.

Comment 5 Vincent Untz 2010-01-14 09:31:28 UTC
But the clock also uses localtime() :-) See format_time(). That's why I don't understand this happens...
Comment 6 Andrey Vihrov 2010-01-14 09:55:31 UTC
(In reply to comment #5)

Hmm, indeed :) The problem really is not that the applet displays wrong time, it just updates the time not when it should have (not on a real minute border), as described above. Say, if the current time is 12:00:01, the applet will calculate that it should sleep 35 seconds instead of 59 (because of the "timeouttime += 1000 * (59 - now % 60);" line), wake up at 12:00:36 and print the time (12:00), then sleep again for a minute to wake up at 12:01:36. So the time is correct, but its updates are shifted by the number of leap seconds.
Comment 7 Vincent Untz 2010-01-14 10:02:23 UTC
Ah, yeah. Right. So we're back to your initial patch :-) I have to run now, but I'll think about it later today.
Comment 8 Andrey Vihrov 2010-04-26 14:44:33 UTC
Changing to UNCONFIRMED since necessary info seems to be provided.
Comment 9 Pacho Ramos 2010-09-09 18:59:00 UTC
Any news on this? Thanks
Comment 10 Pacho Ramos 2011-02-24 17:45:21 UTC
This is still valid with 2.32, would be nice if the fix could be accepted if possible, thanks :-)
Comment 11 Pacho Ramos 2011-04-03 09:24:09 UTC
Do you think is this patch ok to be used downstream at least? Thanks
Comment 12 Vincent Untz 2011-05-23 23:09:37 UTC
Okay, this is finally in. Thanks for the patch!