GNOME Bugzilla – Bug 604317
Clock applet shows slightly wrong time
Last modified: 2011-05-23 23:09:41 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.
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. Thanks.
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 on attachment 149552 [details] [review] Proposed fix Based on your analysis, I believe this patch is not the right way to handle things.
(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. [1] http://en.wikipedia.org/wiki/Unix_time#Encoding_time_as_a_number
But the clock also uses localtime() :-) See format_time(). That's why I don't understand this happens...
(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.
Ah, yeah. Right. So we're back to your initial patch :-) I have to run now, but I'll think about it later today.
Changing to UNCONFIRMED since necessary info seems to be provided.
Any news on this? Thanks
This is still valid with 2.32, would be nice if the fix could be accepted if possible, thanks :-)
Do you think is this patch ok to be used downstream at least? Thanks
Okay, this is finally in. Thanks for the patch!