GNOME Bugzilla – Bug 722465
yesterday/tomorrow labels sometimes wrong
Last modified: 2016-10-09 08:13:16 UTC
Created attachment 266589 [details] today, note Beijing and Jeddah say "tomorrow": this is correct. I've seen the "yesterday" and "tomorrow" labels swapped. It was 1st and 2nd of Jan: perhaps some kind of year change error (arithmetic mod 365 fail?). I haven't looked or tried to reproduce by playing with my clock. Apologies if this is somehow TZ data not gnome-clocks at fault. Gnome-clocks 3.10.1 on Fedora 20. I'll attach three screenshots to show the issue.
Created attachment 266590 [details] Jan 1: Beijing and Jeddah incorrectly say "yesterday" (instead of tmw)
Created attachment 266592 [details] Jan 2: just after midnight, Canadian cities incorrectly say "tomorrow"
Created attachment 267494 [details] my screenshot I have not been able to observe this so far. Is it because you have am/pm time format instead of 24, what is your tzdata version? mine is $ eix timezone-data [I] sys-libs/timezone-data Available versions: 2011n 2012j ~2013a 2013b 2013c 2013d ~2013f-r1 ~2013g ~2013h ~2013i {nls ELIBC="FreeBSD glibc"} Installed versions: 2013d(10:14:21 AM 09/27/2013)(nls ELIBC="glibc -FreeBSD") Homepage: http://www.iana.org/time-zones http://www.twinsun.com/tz/tz-link.htm Description: Timezone data (/usr/share/zoneinfo) and utilities (tzselect/zic/zdump)
(In reply to comment #1) > Created an attachment (id=266590) [details] > Jan 1: Beijing and Jeddah incorrectly say "yesterday" (instead of tmw) Thank you for your report, beijing should be indeed labeled with "tomorrow"
# yum list tzdata tzdata.noarch 2013i-2.fc20 I can't reproduce with today's date. If I get around to it, I will set computer clock back to Dec 31st (as I'm still assuming its a year change bug). I'd be very *very* surprised if this is tzdata bug...
I can consistently reproduce this by setting my machine's date to Jan 1st and then playing around with the time until it is supposed to be "tomorrow" in one of the world clock locations. At that point, the "yesterday" string is displayed instead. See attachment screenshot_jan1_yesterday_bug.jpeg. Also, if I set my date to Jan 2nd, and then change my time so that it is "yesterday" in one of the world clock lcoations, the "tomorrow" string is displayed instead. See attachment screenshot_jan2_tomorrow_bug.jpeg. In the attached screenshots, the clock that corresponds to my local timezone is the Vancouver, Canada clock. This happens both when using an AM/PM clock or 24-hour clock (attachment screenshot_24hour_clock.jpeg).
Created attachment 292582 [details] screenshot_jan1_yesterday_bug.jpeg Local time is Jan 1st in Vancouver, Canada. It is Jan 2nd in Beijing, China, but the "Yesterday" label is being displayed.
Created attachment 292583 [details] screenshot_jan2_tomorrow_bug.jpeg Local time is Jan 2nd in Vancouver, Canada. Time in Anchorage, USA is Jan 1st, but "Tomorrow" is being displayed on that world clock.
Created attachment 292584 [details] screenshot_24hour_clock.jpeg This bug also occurs when using the 24 hour clock.
Created attachment 292585 [details] [review] proposed patch I've created a proposed patch to fix this. It's tested and working in my local environment. This bug appears to be happening because of the way the day_label() function in world.vala checks to see which day label it should display. Right now it does a simple check like this: If (local day) < (remote day) then display "Tomorrow" on the world clock. Else if (remote day) < (local day) then display "Yesterday" on the world clock. Where the 'local day' and 'remote day' above are values between 1 and 365. But it also has to account for the case where the local day may be Dec 31st (365), and the remote day may be Jan 1st (1). In this case it should display "Tomorrow" for the remote location, even though 1 < 365. It accounts for this scenario in the code as follows: if ( d < t ) // If it is Dec 31st here and Jan 1st there (d = 1), then "tomorrow" return d == 1 ? _("Tomorrow") : _("Yesterday"); However this check does not account for the case where it is Jan 2nd at the user's local location. In this case, d < t (since 1 < 2), and d == 1, so it will return the string "Tomorrow" when it should instead be returning "Yesterday".
I am sorry that this patch got forgotten here for so long. Thanks a lot for the analysis and fix. Patch applied.