GNOME Bugzilla – Bug 765897
Wrong weekdays shown for date
Last modified: 2017-10-25 16:25:30 UTC
With 3.20.1-1 on openSUSE Tumbleweed, I get wrong weekdays for dates. I.e. today it's 2nd May 2016 which is a Monday and it's correct shown but in the row/column view it's in the sunday column.
Created attachment 327136 [details] example screenshot
*** Bug 774426 has been marked as a duplicate of this bug. ***
*** Bug 781279 has been marked as a duplicate of this bug. ***
This bug happens after the system timezone changed. The root cause is that spidermonkey does not detect the change of timezone. Even after the timezone changed, the object created by new date() is in the old timezone. But the new Date().toLocaleFormat(..) function which is overridden in js/ui/environment.js:120 uses Glib, so it uses correct timezone. The difference between them makes this bug. Calling JS_ClearDateCaches( https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS_ClearDateCaches) could be a solution according to the documents. But as I tested in GJS console, it does not work well even though I modified to calling this function every time JS statement is evaluated. JS_ClearDateCaches is replaced by another function JS::ResetTimeZone. It is also saying that it is needed to be called when the system timezone changes. 46 diff --git a/js/public/Date.h b/js/public/Date.h 47 index 2324ad7..f9df967 100644 48 --- a/js/public/Date.h 49 +++ b/js/public/Date.h 50 @@ -39,6 +39,22 @@ struct JSContext; 51 52 namespace JS { 53 54 +/** 55 + * Re-query the system to determine the current time zone adjustment from UTC, 56 + * including any component due to DST. If the time zone has changed, this will 57 + * cause all Date object non-UTC methods and formatting functions to produce 58 + * appropriately adjusted results. 59 + * 60 + * Left to its own devices, SpiderMonkey itself may occasionally call this 61 + * method to attempt to keep up with system time changes. However, no 62 + * particular frequency of checking is guaranteed. Embedders unable to accept 63 + * occasional inaccuracies should call this method in response to system time 64 + * changes, or immediately before operations requiring instantaneous 65 + * correctness, to guarantee correct behavior. 66 + */ 67 +extern JS_PUBLIC_API(void) 68 +ResetTimeZone(); So I think that we need to update Spidermonkey to the latest one and a mechanism to detect the system timezone. Is there already one for detecting timezone change?
I forgot to write the way to reproduce it. Reproduce: 1. Change the system timezone in control panel. 2. Navigate months in popup calendar.
For fixing it within the broken session restart the shell: "Alt+F2 r"
Still present in 3.22 (I know, one year old but what can you do with Debian). When using Wayland, Alt+F2 r doesn't work. Will anyone fix this?
> The root cause is that spidermonkey does not detect the change of timezone. The root cause is that why do you need the timezone at all? A Monday 1st of January is Monday 1st of January regardless of timezone.
Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed in the code repository. *** This bug has been marked as a duplicate of bug 678507 ***