GNOME Bugzilla – Bug 736722
Calendar in clock applet makes mistake on week number
Last modified: 2015-07-01 07:19:27 UTC
GNOME version 3.10.2 I've the date and time shown on the top bar. When I click on it, I can see a calendar. I have enabled the week number on the calendar. And I discovered a mistake in the computation of week number. Take date March 23rd 2015 and March 30th 2015, they both are on week numbered 13.
Are you using session with 2 panels - one at top of screen and one at bottom? Or what is full name of session you are using? These days GNOME Applets are no longer part of GNOME session. This product/module is only used in unofficial session - GNOME Flashback.
Only the default panel on the top of the screen (gnome shell). Did a ps efww, but could only see this related to calendars /usr/lib/gnome-shell/gnome-shell-calendar-server Please note I have activated the week numbers of the Clock/Calendar via - Tweak Tool/Top Bar
Thanks for info!
Indeed, I can reproduce this here.
Also with gnome 3.14.1. Week 43 (October 2015) is missing. I think this coincides with the daylight saving time changes in both cases, so most likely the algorithm used to compute the week number is not taking that into account.
Created attachment 290625 [details] [review] Patch So the algorithm works like this: week #1 is the one that contains the 1st Thursday. In order to get the current week number, we follow these steps: - Get the date from the current week's Thursday (at midnight) - Get the date from January the 1st. - See how many days passed from January the 1st to this week's Thursday. - Divide by 7 and add 1. Now, in order to see how many days passed the algorithm calculates the difference (in msecs) and does Math.floor(Math.abs(diffDate) / MSECS_IN_DAY). The problem is that not all days are MSECS_IN_DAY long. During daylight saving time there's one hour missing, so for example the 2nd of April of 2015 is 91 days after January the 1st, but the result of our operation is 90.9583. Since we are rounding downwards, one day is lost. The problem remains until autumn, when there's one day that's one hour longer, that's why there's w43 missing in 2015. Replacing Math.floor() with Math.round() should be enough. As I explained above, diffDate is either a multiple of MSECS_IN_DAY or there's a difference of one hour, so we can safely round the result of the division to the nearest integer.
Review of attachment 290625 [details] [review]: ::: js/ui/calendar.js @@ +101,3 @@ let diffDate = nearestThursday - jan1st; + // Round to nearest integer since days aren't always equally long (due to DST) + let dayNumber = Math.round(Math.abs(diffDate) / MSECS_IN_DAY); This is probably right, but I wonder if it makes sense to throw out the error-prone code altogether. I'll attach a proposal to do that.
Created attachment 290644 [details] [review] calendar: Stop computing week number ourselves Correctly computing the ISO week number is tricky and we already have code in the platform to do it, so just refer its computation to GDateTime rather than doing it ourselves.
- let label = new St.Label({ text: _getCalendarWeekForDate(iter).toString(), + let label = new St.Label({ text: iter.toLocaleFormat('%V'), Yes, that's certainly much better. I wasn't aware of that method. I wonder why this was not used from the beginning though...
Attachment 290644 [details] pushed as 1e8e5d4 - calendar: Stop computing week number ourselves
*** Bug 742354 has been marked as a duplicate of this bug. ***
Sorry for spamming this bug, but any chance we can get an update into F21 for this?
(In reply to Olivier Crête from comment #13) > Sorry for spamming this bug, but any chance we can get an update into F21 > for this? Yes, if you can find a Fedora packager who is not busy resolving blocker bugs for 3.16 ...
Bug confirmed with 3.14.2 week 13 at March 23rd 30th week 43 missing
*** Bug 745912 has been marked as a duplicate of this bug. ***
*** Bug 747004 has been marked as a duplicate of this bug. ***
*** Bug 747240 has been marked as a duplicate of this bug. ***