GNOME Bugzilla – Bug 417461
Evolution time zone data not updated for new Canada/US Daylight Savings Time
Last modified: 2009-04-13 06:09:00 UTC
Please describe the problem: Although Ubuntu Edgy correctly updated the time to reflect the earlier Daylight Savings Time (confirmed with zdump -v /etc/localtime | grep 2007), the evolution calendar stayed on standard time. Check of /usr/share/evolution-data-server-1.8/zoneinfo/America/Halifax.ics confirmed that now out-of-date data were being used. Steps to reproduce: 1. Start up evolution 2. Look at the current time on the calendar 3. Actual results: Time is one hour earlier than expected Expected results: Correct time Does this happen every time? Yes Other information: I am using evolution with an MS Exchange server. However, the issue occurs even when disconnected from the server (and I verified that the server is on Daylight Savings time). Simple work-around is to manually edit the .ics file, after which evolution behaves correctly.
I can confirm this report. I'm using Ubuntu Edgy Eft AMD64. Line 19 of /usr/share/evolution-data-server-1.8/zoneinfo/America/New_York.ics has the wrong definition for DST: RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU I modified the rule to use the new definition of DST: RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU I did not change the definition for standard time, assuming that this will be resolved by November.
that fixes it, but other calendars are still screwed up. if you look through the different *.ics files, they all have the old tz information. it's almost like you have to go through and update each section that contains the DAYLIGHT information....no?
(In reply to comment #2) > that fixes it, but other calendars are still screwed up. > > if you look through the different *.ics files, they all have the old tz > information. > > it's almost like you have to go through and update each section that contains > the DAYLIGHT information....no? > actually, i mean any "recurring" apts need to be modified, i've found that new, regular apts seem to work "OK".
please ask your distributor (ubuntu) to provide an updated package, including the patch for bug 301363.
Isn't the real bug that Evolution doesn't use the system timezone files?
*** Bug 417475 has been marked as a duplicate of this bug. ***
Well, the real bug seems to be that there's timezone data stored throughout the calendar's .ics file that doesn't get updated when the underlying time zone data changes. (And if that's fixed, the problem that the timezone data that evolution ships only reflect the current rules and not the change in the rules over time would be a problem.) (It would be nice to use the data shipped with the system, but it may not be practical since there may not be a good way to get sufficient information out of it, especially the information needed to generate .ics / .vcs files for exchange with other calendar programs.)
I can confirm that on 2.10.0 under Ubuntu Feisty Beta that this problem still exists. When I attempt to schedule a meeting in UTC, the time is off by 1 hour in my local timezone (in this case, Americas/Denver).
This is still broken; I'm using Evo built from the very latest SVN trunk as of this morning, running on Ubuntu 7.10, and right now my times in Evo are an hour off due to the change LAST YEAR of the DST start/stop in the U.S.! This is extremely embarrassing. My system time is correct; the system tzinfo was fixed. But every meeting request I get says (for example) 4-5pm, but when I accept it my calendar lists it as 5-6pm. Also 5-6pm appears in the autogenerated reply. It's pretty bad that after an entire release cycle we're still using out of date timezone information for a calendar/meeting application, where timezone is one of its most critical aspects :-/.
I still have this exact problem in Debian testing using gnome 2.18.3 and evolution 2.10.3. Is this caused by the change in date of daylight savings? If so, should it just use system time which is correct? I guess it will be fixed Sunday, but this still looks pretty bad.
Evolution time zone had been integrated with system time zone during 2.12.x afair. Do you still see the issue ? Can you please verify in later version 2.22.x or 2.24.x and report back, thanks.
Thanks for taking the time to report this bug; however, closing due to lack of response of the reporter, sorry. if you still see this issue with a current release of evolution (2.26.0 or later), please reopen. thanks in advance.