GNOME Bugzilla – Bug 572516
Time zone for Western Australia is incorrect
Last modified: 2009-07-31 18:16:48 UTC
Please describe the problem: Western Australia is currently on Daylight Saving Time. However Evolution is not implementing DST while the Ubuntu system time does implement DST. This leads to a calendar scheduling mismatch. Standard Time: +08 hrs UTC Daylight Time: +09 hrs UTC (reverts to standard time at the end of March 2009) Patch should be easily doable. Steps to reproduce: 1. Install Ubuntu with the settings pointing to Australia, with timezone set to Australia/Perth 2. Create an appointment for February/March 2009 and another for April 2009 3. On the menu bar, click the date. Notice the difference between the appointments in February, and the one in April. Actual results: Calendar schedule mismatch Expected results: Might be too early/late for an appointment Does this happen every time? YES Other information: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/319856 http://ubuntuforums.org/showthread.php?t=382766
srag, might this be something to fix for 2.24.5?
Don't we read timezones from the system's tzdata now?
Created attachment 129196 [details] Screenshot of Ubuntu's schedule and Evolution's schedule Notice the difference between the time listed for the appointment Stochastic Process. In Evolution it is 5 pm, while on the system time it is 6 pm
Chen, can you look at this?
suman had made a fix for a similar issue last week. It might fix this also. suman?
Created attachment 129385 [details] [review] patch from libical-upstream [I had posted this on the libical m-l. Re-posting here just to have some context] Present output (from the 'timezones' test program under src/test): Australia/Perth: day 000: first failed: libc 2009-02-13 12:00:00 dst 1 != libical 2009-02-13 11:00:00 dst 0 Australia/Perth: day 044: okay again: libc 2009-03-29 11:00:00 dst 0 Australia/Eucla: day 000: first failed: libc 2009-02-13 12:00:00 dst 1 != libical 2009-02-13 11:00:00 dst 0 Australia/Eucla: day 044: okay again: libc 2009-03-29 11:00:00 dst 0 *** Summary: 401 zones tested, 88 days failed, 146277 okay => 0% failed *** Output after applying attached patch: Australia/Perth: day 254: first failed: libc 2009-10-25 11:00:00 dst 0 != libical 2009-10-25 12:00:00 dst 1 Australia/Eucla: day 254: first failed: libc 2009-10-25 11:00:00 dst 0 != libical 2009-10-25 12:00:00 dst 1 *** Summary: 401 zones tested, 222 days failed, 146143 okay => 0% failed *** A little bit of explanation: libical operates on RRULES. The STANDARD component has a rule, the DAYLIGHT component has a rule. All the dates that fall within the limits of these rules fall into one or the other categories. GLibc does not operate that way. Given a point in time, it tries to calculate if any daylight savings rule applies to that given instant. The time offset is then calculated accordingly. This is precisely the reason why the test program fails even after applying the patch. At present, there is no rule for Australia(Perth/Eucla) to govern what happens on the last Sunday of October in 2009. i.e. there is no apparent switch to DST. 9 out of 10 times, it is just because the rule may not be officially accepted yet and not because the rule was intended to removed altogether. With the patch, libical tries to extrapolate (and yes, predict) the last applicable transition to the relevant date in the current year. Why should I apply the patch if it is not the complete fix anyway? As of now, libical provides wrong timezone data. i.e. it is indeed DST in those two locations right now but libical says otherwise. With the patch, libical tries to provide the correct timezone offsets for all "known and confirmed" data and tries to predict for the "unconfirmed and most-likely-to-be-true" data. ** The patch also addresses this issue: libical currently provides DAYLIGHT and STANDARD components that are applicable for exactly one year, beginning the instant the timezone was requested. This also extends to the test program which tests the correctness of the information provided for one year, beginning the instant the test program began. This behavior provides inconsistent results. For example, the RRULE generated for the DAYLIGHT component (for America/Sao_Paulo) in February 2008 is different from that generated in February 2009 ==> Using the RRULE for 2009 is incorrect while still in 2008. So, we need to use the transitions in this year alone to generate the RRULES for the DAYLIGHT and STANDARD components.
Patch committed stable (gnome-2-24) branch as r663 http://svn.gnome.org/viewvc/libical?view=revision&revision=663 This fix will be a part of evolution-data-server-2.24.5 Upstream, the fix will be available with libical-0.44
2.24.5 is released. This bug can be closed too if the reporter can verify that it fixes the issue.. :-)
Thanks! I wish I could have verified the same, but since Evolution was not on the Intrepid repository when DST ended, I could not test it. Didn't want to mess with my system by downloading the tar file. An update: On May 16th, Western Australia had a referendum that did away with Daylight Saving Time. References: http://www.timeanddate.com/news/time/western-australia-no-to-dst.html and http://www.abc.net.au/news/stories/2009/05/16/2572628.htm I think we have to update the time zone information so that DST settings are not applied in October.
Thanks for the information. I've revision 932 of an upstream libical, which evolution-data-server is using now, and for example Australia/Perth is without the daylight saving time, which should be correct with respect of your above comment. I'm closing this as fixed. Note that most likely your timezone is picked from the system timezone now. BEGIN:VCALENDAR PRODID:-//citadel.org//NONSGML Citadel calendar//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:/citadel.org/20070227_1/Australia/Perth X-LIC-LOCATION:Australia/Perth BEGIN:STANDARD TZOFFSETFROM:+0800 TZOFFSETTO:+0800 TZNAME:WST DTSTART:19700101T000000 END:STANDARD END:VTIMEZONE END:VCALENDAR