GNOME Bugzilla – Bug 301363
Evolutions timezone data is seriously incomplete and out-of-date
Last modified: 2013-09-10 13:42:14 UTC
Please describe the problem: Evolutions seems to have problems with timezone data. It probably uses out of date information for timezones. Steps to reproduce: 1. Change your Evolution timezone to Asia/Tehran. 2. Set a meeting on April 20, 2005, starting on America/Los_Angeles time 08:00. Actual results: A meeting is created on Tehran time 18:30 (6:30 PM). Expected results: The meeting should be on 19:30, since (on April 20) Los Angeles is 7 hours behind UTC while Tehran is 4:30 hours after UTC, which would result in 11:30 hours of difference, NOT 10:30 hours. Does this happen every time? Yes. I could even reproduce it on both Evolution 2.0.4 and Evolution 2.2.2. Other information: Probably an updated timezone data may solve the problem (or it may not).
From what I can see in the sources, it should be a problem in data files of libical.
I am writing a python script to convert the Olson timezone database (tzdata) to ".ics" timezone files. I'm currently using 1970 as cutting time, but could change that to something earlier (if it's useful to go back) or something later (if the accuracy of twentieth century times is not that important).
Created attachment 45638 [details] proper timezone for Asia/Tehran (cutting at 1970)
Created attachment 45639 [details] proper timezone for America/Los_Angeles (cutting at 1970)
Created attachment 45640 [details] proper timezone for Asia/Jerusalem (cutting at 1970)
Attaching three good examples. The Los Angeles one would not make a difference from what we currently have for years later than 1987, but the other ones (specially the Asia/Tehran one) make lots of difference for now and the future. Tehran is currently wrong for about six months a year.
Rodrigo suggested on IRC that sush (and vivek?) may be able to test these for Outlook compatiblity and arrive at something that works fine with Outlook...
Sarfraaz?
Chen/Sarfraaz : could you please test this out ?
Bug 300603 may be a duplicate of this.
Oops, I meant Bug 300606 may be duplicate of this.
retargetting from 1.3 to 1.5 to get rid of that busted milestones (as discussed with harish on irc), though i'd prefer a 1.4.x target milestone.
*** Bug 300606 has been marked as a duplicate of this bug. ***
According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360981 America/Indiana/* needs an update as well.
Doesn't block 311332 anymore, since Iran has cancelled daylight saving.
chen/sarfraaz: ping?
Looking into it.
removing old target milestone, setting new one.
reassigning bugs assigned to dinesh layek to avoid rotting.
chen: poke! this is even more important as bug 349078.
Updated the timezone information for Jerusalem and Los_Angeles.
Hmm, for some reason, Los Angeles now shows up where Jerusalem used to be on the map. I wonder if thats related to this patch
From CVS HEAD, in calendar/libical/zoneinfo/Asia/Jerusalem.ics: ... TZID:/softwarestudio.org/Olson_20050423_1/America/Los_Angeles X-LIC-LOCATION:America/Los_Angeles ... This looks out of place.
Oh, the two files committed were the same. Updated the right file for Jersusalem.
Can we close this then?
Created attachment 80963 [details] [review] Fixes the bug.
I have taken the latest timezone changes from ftp://elsie.nci.nih.gov/pub/ and made a patch using the vzic icalendar timezone converter which can be picked up from http://dialspace.dial.pipex.com/prod/dialspace/town/pipexdsl/s/asbm26/vzic/. The README in the vzic converter specifies why the more than one RDATE's or RRULES cannot be used and other compatibility issues. http://www.twinsun.com/tz/tz-link.htm has the information about the timezone mailing list in which the errors present in the existing timezone database can be discussed and the database would be updated.
(In reply to comment #25) > Can we close this then? No. There are several other timezones that need fixing, and this needs to be done continuously, as they change quite frequently. We need a script to keep the list update for each release, or a mechanism to extract the data at runtime from installed tzdata packages. (In reply to comment #26) > Created an attachment (id=80963) [edit] > Fixes the bug. I can't see how it does. Look at the data for Jerusalem, for example, to see how it doesn't fix the problem.
If evolution would just use tzdata, this whole problem would not occur.
(In reply to comment #28) > (In reply to comment #25) > > Can we close this then? > > No. There are several other timezones that need fixing, and this needs to be > done continuously, as they change quite frequently. We need a script to keep > the list update for each release, or a mechanism to extract the data at runtime > from installed tzdata packages. The patch attached at comment#36 has the latest tzdata available at ftp://elsie.nci.nih.gov/pub/ . I have subscribed to the mailing list to keep track of the changes. Yes, having a script is better idea and is on the cards. > > (In reply to comment #26) > > Created an attachment (id=80963) [edit] > > Fixes the bug. > > I can't see how it does. Look at the data for Jerusalem, for example, to see > how it doesn't fix the problem. Please send a mail to the timezone mailing list about the latest timezone information for Jerusalem. The patch which is attached at comment#5 would introduce interoperability issues. Once the tzdata is updated, we will be updating the ics files in libical. Matthias, By tzdata, do you mean the data present at ftp://elsie.nci.nih.gov/pub/tzdata2007a.tar.gz ? If so how would using tzdata solve the issue if it does not have the latest tz information ? I would be glad to know if there is any other location to get the latest tzdata.
(In reply to comment #30) > Please send a mail to the timezone mailing list about the latest timezone > information for Jerusalem. The timezone information for Jerusalem comes from the information from tzdata. The problem here is that the information in libical, apart from being outdated, is over-simplified, and thus loses the necessary information to make the switches properly. > The patch which is attached at comment#5 would > introduce interoperability issues. Then we are back at the first step... > Matthias, By tzdata, do you mean the data present at > ftp://elsie.nci.nih.gov/pub/tzdata2007a.tar.gz ? If so how would using tzdata > solve the issue if it does not have the latest tz information ? It does have the latest tz information. Matthias is suggesting that we use the copy of tzdata already available on the user's system instead of having the data duplicated, like from the package named "tzdata" in Fedora Core.
Matthias, sorry for jumping the gun. I just created the ics files to be compatible with exchange. I generated the data using --pure option with the vzic converter which provided the right timezone information for the Jerusalem. But the problem with using these information is that it would introduce interoperability issues. So without the --pure option enabled the ics files generated will not have all the information.
Roozbeh, yes right i got it. After regenerating the ics files, I see many more timezones with missing information. I will try to fix it as a whole asap.
Roozbeh is right. I was suggesting that it is suboptimal to have 2 redundant sources of timezone information in the system.
When will the patch be committed? you know that March 11, the daylight time will begin.
Exchange does not accept the timezone information with multiple rdates/RRULES etc. The bug 394473 happens due to the same. I have made a patch with the latest updates and have verified them with exchange server and some with the information at timeanddate.com. Some may not be accurate due to compatibility issues. I am thinking of the following solution for evolution-2.12. Re-use the timezone information present in the system. Provide API's to get the simplified or pure Vtimezone Components which the providers (file/exchange/caldave etc.) can use depending on their needs.
Created attachment 83954 [details] [review] Updated timezones.
If there are any other timezone which are out of date that are not covered by this patch, please feel free to add a comment. I will get this patch in today after a review. Harish, review please :-).
*** Bug 392170 has been marked as a duplicate of this bug. ***
Yes, "Re-use the timezone information present in the system" looks like the best solution. Thus evolution-data-server need not to ship the timezone info of its own and we need not to worry the bugs like this one anymore.
Chen : The patch looks good to commit. We still need to keep watching for reports on the timezones where RDATE->RRULE changes for Exchange inter-operability may have introduced inaccuracies and tackle them as they come.
Fix has been committed to svn HEAD and stable branch.
Is there another stable update planned which will include these changes or is it up to the distros?
(In reply to comment #37) > Created an attachment (id=83954) [edit] > Updated timezones. > I just applied this to get a fix in for the upcoming US DST changes. Note that applying this patch to evolution-data-server does not solve the whole problemfrom the user perspective: if you accepted meetings scheduled between 3/11 and 4/(whatever) while running the unpatched E-D-S, those meetings will be an hour off after starting the patched version. I had to delete all my recurring meetings, go find the original invitations, and re-accept them in order to see them show up at the correct times on my calendar.
Ubuntu bug about that: https://launchpad.net/ubuntu/+source/evolution-data-server/+bug/79323 "Binary package hint: evolution-data-server-common From Bug #72125: Daylight Saving changes in Western Australia Western Australia is going to be starting a trial of Daylight Saving on December 3, 2006 until March 31, 2007, moving us from UTC+8 to UTC+9 over that time period. This has been fixed in dapper and edgy in the tzdata package (approved for update to respective updates as at 15/01/07) but the evolution ICS file remains unchanged. The file that (I believe) requires fixing is: /usr/share/evolution-data-server-1.8/zoneinfo/Australia/Perth.ics ... http://librarian.launchpad.net/5745345/Perth.ics Updated zoneinfo file for Australia/Perth for daylight savings. BTW, I've updated my local copy of the file /usr/share/evolution-data-server-1.8/zoneinfo/Australia/Perth.ics as per attachement. I think this is correct (and appears to work), but should be checked. Cheers, Daniel."
*** Bug 416160 has been marked as a duplicate of this bug. ***
(In reply to comment #44) > I just applied this to get a fix in for the upcoming US DST changes. Note that > applying this patch to evolution-data-server does not solve the whole > problemfrom the user perspective: if you accepted meetings scheduled between > 3/11 and 4/(whatever) while running the unpatched E-D-S, those meetings will be > an hour off after starting the patched version. I had to delete all my > recurring meetings, go find the original invitations, and re-accept them in > order to see them show up at the correct times on my calendar. > I've run into the same problem. All my old repeating appointements are incorrectly moved an hour forward, now. I'm trying to figure out a way to make a global substitute to ~/.evolution/calendar/local/system/calendar.ics ao I don't have to re enter all the appointments I have stored.
(In reply to comment #47) > I've run into the same problem. All my old repeating appointements are > incorrectly moved an hour forward, now. > > I'm trying to figure out a way to make a global substitute to > ~/.evolution/calendar/local/system/calendar.ics ao I don't have to re enter all > the appointments I have stored. > Well not only can't I figure out a way to fix existing appointments, outlook meeting notices are not being saved correctly. The following is an outlook notice for a recurring appointment from 11:30-01:00PM. When I accept it, it comes up as 12:30-2:00 for March 12-30. Then it comes up 11:30-01:00 from April 2 to October 26. Then it's wrong again for October 26 to November 2. (Ical below) ------ BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:(GMT-05.00) Eastern Time (US & Canada) X-MICROSOFT-CDO-TZID:10 BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20070312T181329Z DTSTART;TZID="(GMT-05.00) Eastern Time (US & Canada)":20060621T113000 SUMMARY:LUNCH UID:{6664C367-D1B8-4955-9CCF-F2DA028254DB} ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Weber, Ch ris":MAILTO:Chris.Weber@xerox.com ORGANIZER;CN="Weber, Chris":MAILTO:Chris.Weber@xerox.com LOCATION: DTEND;TZID="(GMT-05.00) Eastern Time (US & Canada)":20060621T130000 RRULE:FREQ=WEEKLY;WKST=SU;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR DESCRIPTION:\N SEQUENCE:11 PRIORITY:5 CLASS: CREATED:20060620T145445Z LAST-MODIFIED:20070312T181329Z STATUS:CONFIRMED TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:-1 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20060620T145451Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20070312T181329Z END:VEVENT END:VCALENDAR
> Well not only can't I figure out a way to fix existing appointments, outlook > meeting notices are not being saved correctly. The following is an outlook > notice for a recurring appointment from 11:30-01:00PM. When I accept it, it > comes up as 12:30-2:00 for March 12-30. Then it comes up 11:30-01:00 from April > 2 to October 26. Then it's wrong again for October 26 to November 2. Yup, I'm seeing the same problem. I have a recurring appointment in the "personal" calendar "On This Computer" that's getting correctly shifted around. This seems to have been the sole effect of applying the patch. However, every meeting in the calendar "Calendar" (which is stored on the Exchange server) is broken for the next 3 weeks. This includes non-recurring meetings that were sent today, i.e. after all systems involved have set their clocks. This is occurring with a patched sExchange server and patched lookOut! clients (the latter being used to send the invites.) Looks like this is a problem specifically for the exchange connector. How can I help solve it?
I am currently working out a patch to migrate all the old timezone data present in meetings created in the past to the new ones. Will get it in asap. The timezone for perth has been updated in evolution. You can find it at http://svn.gnome.org/viewcvs/libical/trunk/zoneinfo/Australia/Perth.ics?view=markupI have validated it against http://timeanddate.com/worldclock/results.html?query=perth and exchange server. Daniel, do you have any authentic information or any site from where i can confirm that the Timezone information provided at http://librarian.launchpad.net/5745345/Perth.ics is the right one ?
(In reply to comment #49) > Looks like this is a problem specifically for the exchange connector. > Just to be specific for my problem, I don't use the exchange connector (I havn't tried the latest version, but our admins locked me out somehow last time I tried). This was an ICal I sent from our exchange via web access to myself.
(In reply to comment #51) > (In reply to comment #49) > > > Looks like this is a problem specifically for the exchange connector. > > > > Just to be specific for my problem, I don't use the exchange connector (I > havn't tried the latest version, but our admins locked me out somehow last time > I tried). This was an ICal I sent from our exchange via web access to myself. > Well thanks to a co-worker I not understand what happened and was able to change the rules for the exchange TZID. (For some reason it sometimes gives me "TZID:(GMT-05.00) Eastern Time (US & Canada)" and sometimes "TZID:GMT -0500 (Standard) / GMT -0400 (Daylight)" both were already in ~/.evolution/calendar/local/system/calendar.ics By changing their rules I can now interact with the rest of the company again. (Instead of being off for 3 weeks :). That's good enough for me.
I also don't use the Exchange Connector for the same reason as Chris. I encountered the same problem Chris had with ics files from Outlook users. The problem seems to be that Outlook/Exchange uses the same timezone identifier as it used before. In my case, the time zone is named "GMT -0500 (Standard) / GMT -0400 (Daylight)". This timezone already existed in my calendar.ics file that Evolution uses (presumably because it imported it previously when I recieved an Outlook meeting invite some time ago). The Exchange server was apparently updated so that this timezone now has the new recurrance rules, rather than creating a new timezone. Evolution apparently doesn't update the timezone settings when it already has that timezone in the calendar (can't say I blame it, MS's solution was pretty much a hack). To fix this for existing Outlook/Exchange-based appointments, I edited the recurrence rules in my calendar.ics for that timezone to match what Outlook was sending out now: BEGIN:STANDARD ... RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11 ... END:STANDARD BEGIN:DAYLIGHT ... RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3 ... END:DAYLIGHT Hope this helps.
I hand edited the New_York.ics file and that seemed to fix the problem -- the red line across the day view of the calendar was at the correct time. However, it turned out that all my repeating appointments are shifted later by an hour. Not only that, but when I tried to move one, I was not allowed to. I get a pop-up window that asks if I want to change just this instance or all instances. No matter which I choose, I end up getting another pop-up that tells me: Object ID already exists. The only way out is to cancel. So it seems that the problem is deeper than just that .ics file. What value in the appointment data in .evolution/calendar/local/system/calendar.ics tells evolution what timezone to use? I suppose it must be the DTSTART and DTEND lines, but these refer to /softwarestudio.org/Olson_20011030_5/America/New_York... So is that information compiled into evolution_data_server?
jslavin: Most of the problems you describe are mentioned in the comments above (except for the Object ID one). The updated timezone for evolution is softwarestudio.org/Olson_20070227_6/America/New_York. I think you'll have to manually update your post-Mar 11 appointments to use this timezone instead of the Olson_20011030_5 one. One way to do this is to delete the existing appointment and re-add it (manually or re-accept an invite). Alternatively, you can hand-edit the appropriate calendar.ics file and use a global search and replace (or a more specific one if you just want to change post-Mar 11 appointments).
Is there a script that could do this conversion? I have dozens of meeting invites that I'd have to move manually. - A
(In reply to comment #55) [...] > The updated timezone for evolution is > softwarestudio.org/Olson_20070227_6/America/New_York. > > I think you'll have to manually update your post-Mar 11 appointments to use > this timezone instead of the Olson_20011030_5 one. One way to do this is to > delete the existing appointment and re-add it (manually or re-accept an > invite). [...] I dunno about that, I've tried re-accepting invites until I'm blue in the face (after rebuilding EDS with the patched .ics files from chenthill's patch in comment #37) and everything's still an hour off until April. I'm in Mountain time (Denve CO) and I've verified that America/Denver.ics contains what appear to be correct values: TZID:/softwarestudio.org/Olson_20070227_6/America/Denver X-LIC-LOCATION:America/Denver BEGIN:DAYLIGHT TZOFFSETFROM:-0700 TZOFFSETTO:-0600 TZNAME:MDT DTSTART:19700308T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0600 TZOFFSETTO:-0700 TZNAME:MST DTSTART:19701101T020000 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD - Ole
What's important is not only if the timezone is up to date (e.g. in your case, the "/softwarestudio.org/Olson_20070227_6/America/Denver" timezone), but also if the appointments you're (re-)adding are using that timezone. Each meeting request will specify which timezone the meeting is for. If the requests are from Outlook, non-Evo users, or Evo users who haven't updated their system, chances are, those invites are not using the up-to-date "Olson_20070227_6" timezone. So, deleting your existing appointment and re-accepting it from a meeting request that contains an old timezone identifier will not help you. The course of action you need to take depends on which situation you are in. For instance, if the problem is that the meeting notices are using an old timezone, I think the easiest thing for you to do would be to accept the meeting, and then edit the timezone its using via manual edit to your calendar.ics (don't forget to do an 'evolution --force-shutdown' afterwards to force e-d-s to restart). To find out what situation you're in, you may need to open the meeting.ics attachment in a text editor and eyeball the ical entries for both the appointment and the related timezone data, which should be included. I just did a global search and replace to change all appointments that were using the old Olson_2001... string to use the Olson_2007... one. This is not technically correct, as old appointments (for previous years) will end up using the new DST rules, but I don't have to keep perfect track of appointments for previous years. If you do, then you'll only want to change the appointments for 2007. If your problem is that the timezone settings for your meeting requests was updated, but the timezone identifier stayed the same (as in the case of Outlook/Exchange in my work environment), then you need to update your calendar.ics to change the recurrence rules for that timezone. Evolution won't update an existing timezone's rules. See my comment above on how I accomplished this. BTW, this will also render previous years' appointments incorrect, but that's the fault of the appointment sender's calendar software, not Evolution. I suppose you could go about changing it by copying and renaming the existing timezone data, then putting all existing appointments to using the copied timezone, but in general it's probably not worth the effort.
BTW, it seems like updating evolution's timezone data is much more confusing than updating a typical Unix's timezone data. I don't know if this is a limitation in ical's timezone formats, but it seems so. It looks like ical DST switchovers are like recurring appointments, and it only allows one recurrance rule per switchover. Compare that with the Unix tz handling, which specifies each switchover for a timezone, and therefore you can update future switchovers (like for 2007) without affecting previous years, and still have it considered the same timezone. What would be really nice would be the ability to specify multiple recurrance rules for each switchover, so then the update to fix this would have just been to cut off the old recurrance rule at 2006 and insert a new one for 2007 onward, without having to change the actual timezone used. Of course, that wouldn't handle other servers' timezone usage, but IMO that's not Evo's fault.
Created attachment 84600 [details] updated America/New_York.ics file with additional DAYLIGHT/STANDARD sections
Comment on attachment 84600 [details] updated America/New_York.ics file with additional DAYLIGHT/STANDARD sections The attached updated America/New_York.ics file includes multiple BEGIN:DAYLIGHT and BEGIN:STANDARD sections, which seems to fix the problems with event recurrences which straddle the recent time change rules.
*** Bug 418323 has been marked as a duplicate of this bug. ***
(In reply to comment #58) > > The course of action you need to take depends on which situation you are in. > For instance, if the problem is that the meeting notices are using an old > timezone, I think the easiest thing for you to do would be to accept the > meeting, and then edit the timezone its using via manual edit to your > calendar.ics (don't forget to do an 'evolution --force-shutdown' afterwards to > force e-d-s to restart). > > To find out what situation you're in, you may need to open the meeting.ics > attachment in a text editor and eyeball the ical entries for both the > appointment and the related timezone data, which should be included. > > I just did a global search and replace to change all appointments that were > using the old Olson_2001... string to use the Olson_2007... one. This is not > technically correct, as old appointments (for previous years) will end up using > the new DST rules, but I don't have to keep perfect track of appointments for > previous years. If you do, then you'll only want to change the appointments for > 2007. > > If your problem is that the timezone settings for your meeting requests was > updated, but the timezone identifier stayed the same (as in the case of > Outlook/Exchange in my work environment), then you need to update your > calendar.ics to change the recurrence rules for that timezone. Evolution won't > update an existing timezone's rules. See my comment above on how I accomplished > this. > Thanks for an eminently readable explanation and suggestions. I was able to get my calendars working by shutting down Evo and running the following commands: perl -pi*.olcbak -e 's/Olson_20011030_5/Olson_20070313_1/g' `find .evolution -name \*ics` perl -pi*.olcbak2 -e 's/BYDAY=-1SU;BYMONTH=10/BYDAY=1SU;BYMONTH=11/g; s/BYDAY=1SU;BYMONTH=4/BYDAY=2SU;BYMONTH=3/g' `find .evolution -name \*ics` ...and then restarting evo. Unfortunately, in the course of trying to get things working I've deleted many recurring appointments. Now I find that I can't come up with a search term that will return just calendar requests; apparently Evo treats them specially and doesn't apply normal searching rules. (submitted as Bug 418425.) One step back, two steps... sideways? Sigh. Anyhow, thanks for the exposition!
When you're using the exchange connector you can't edit the files by hand (or by script) because they're stored on the server. As soon as you reconnect it munges them again and its back to square one. Obviously evolution can parse the meeting invites correctly because they display with the correct time in the email. Can't the calendar use the same code to parse the display times that the email component uses?
*** Bug 418074 has been marked as a duplicate of this bug. ***
*** Bug 417936 has been marked as a duplicate of this bug. ***
*** Bug 417885 has been marked as a duplicate of this bug. ***
This may be related: I've noticed in the last week that the current time marked by a red line through Evolution's daily or weekly calendar is an hour behind real time as shown on my system clock. My computer's clock is set to UTC, the system's time zone is set to US/Pacific, and Evolution's time zone is set to America/Los Angeles. My system time zone data file was updated just last month with tzdata-2006m, and I updated Evolution just this morning to 2.8.2.1 (and evolution-data-center to 1.8.2).
*** Bug 418720 has been marked as a duplicate of this bug. ***
*** Bug 423102 has been marked as a duplicate of this bug. ***
*** Bug 433953 has been marked as a duplicate of this bug. ***
I just added a comment to Bug 417461 which is the same basic problem as this one, stating that this is still not fixed in the latest Evolution checked out of SVN, build, and installed this morning on my new Ubuntu 7.10 system. Highly embarrassing that even after at least one entire major release cycle after the timezone change we STILL do not have the right information in Evolution's calendar--all my meetings all week long are messed up due to this!
Just a question, out of sheer dumb curiosity -- is there any work being done to have Evo using the system's time zone data (like, say, tzdata in *IX)? This was suggested by chenthill earlier on, but I see no other indications this is being pursued.
Evolution is already using system time zone data as of version 2.12. (That really should have been mentioned in the release notes.) That said, I'm not sure we can do anything about events being off when DST dates change. If my understanding of the iCalendar standard is correct, the standard calls for embedding time zone information into iCalendar events rather than having the events reference an external, up-to-date source for time zone information. So even though we're using system time zone data now, if DST dates for a particular time zone change then existing appointments that reference that time zone will still have the old DST dates embedded in them. New appointments, on the other hand, will get the new DST dates embedded in them.
Okay, I finally got fed up with missing meetings and took two and a half days to upgrade all of evolution's dependencies and then upgrade evolution itself to 2.22. When the upgrade was complete I opened my local calender, deleted today's 10:00 meeting (which was in the 11:00 slot), opened up the meeting invitation and re-accepted it. The meeting was once again put back in the 11:00 time slot instead of 10:00 where it is supposed to go. I scanned my file system for any old instances of Los_Angeles.ics, found one from a 'kdepim' package, deleted it, then deleted and re-accepted the meeting again. Same result. What am I missing here? As for the ICS calendar data containing embedded time zone information, it looks to me like the embedded daylight savings range is correct in ICS. If the ICS data is correct and tzdata is correct, I don't understand how evolution is getting it wrong. Here's the data: BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:GMT -0800 (Standard) / GMT -0700 (Daylight) BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT X-MICROSOFT-CDO-MODPROPS;X-MODPARAM=1:attendee,BEGIN,class,created,descript ion,dtend,dtstamp,dtstart,duration,END,last-modified,location,organizer,pr iority,recurrence-id,sequence,status,summary,transp,uid,x-microsoft-cdo-al ldayevent,x-microsoft-cdo-apptsequence,x-microsoft-cdo-attendee-critical-c hange,x-microsoft-cdo-busystatus,x-microsoft-cdo-importance,x-microsoft-cd o-insttype,x-microsoft-cdo-intendedstatus,x-microsoft-cdo-owner-critical-c hange,x-microsoft-cdo-ownerapptid DTSTAMP:20080314T180105Z DTSTART;TZID="GMT -0800 (Standard) / GMT -0700 (Daylight)":20080318T100000 ... You can see by the second RRULE tag that it sets daylight time (-0700) on the 2nd sunday of the 3rd month -- March 9.
The problem is likely because the old timezone data is embedded in the meeting itself. That's iCalendar for ya.
Just where in the above ICS file do you see old timezone data?
This is the timezone data in the ICS: BEGIN:VTIMEZONE TZID:GMT -0800 (Standard) / GMT -0700 (Daylight) BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU END:DAYLIGHT END:VTIMEZONE These settings reflect the correct (current) DST rules, namely, that DST starts on the 2nd Sunday in Marc (FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU) and ends on the 1st Sunday in November (FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU). I haven't looked into this problem in a while, but IIRC, you can run into problems if the TZID in the appointment has the same name as a TZID already defined in the calendar. It's pure speculation, but Evo may be ignoring the TZ rules given above and using the rules it already has stored for the TZID "GMT -0800 (Standard) / GMT -0700 (Daylight)", which may be the old rules. It's unfortunate that Exchange doesn't give the timezone a different name to distinguish 2007+ rules from 2006- rules.
Confirmed. I renamed my current ~/.evolution/calendar/local/system/calendar.ics file, restarted evolution, accepted a new meeting invite, and it was placed in the correct time slot. Of course, doing so deleted all of my prior meetings so this is not a suitable solution. It seem to me that evolution should not be caching time zone rules at all. Even ignoring the rules changes for a given zone, how would evolution figure out whether "GMT -0800 (Standard) / GMT -0700 (Daylight)" is supposed to use America/Los_Angeles rules or Mexico/BajaNorte or Pacific/Pitcairn, for example? (The latter two are still in standard time.) Although it's very unlikely, suppose someone got two meeting invites this week: one from a person whose computer was set to the America/Los_Angeles zone and another who mistakenly set their computer to America/Tijuana. They are fairly close together on the time zone map, but Tijuana doesn't go to daylight savings until April 6. How would evolution treat these two meetings?
Or at least it should use the timezone data provided in the appointment over whatever is cached in the ics file, and if it's going to normalize the timezones, add a new (and differently named) timzezone section to the ics file for the appointment once it's in the calendar.
*** Bug 523274 has been marked as a duplicate of this bug. ***
I started a discussion about fixing the insufficient time zone handling in Evolution on the Evolution hackers list. My motivation is to get it fixed as soon as possible and in a way that also works for SyncEvolution. During the course of the discussion it was pointed out that this issue here is considered resolved because it was about the out-dated time zone definitions used by Evolution, not about general deficiencies around time zone handling in general. Therefore I have created a new issue (bug 528902) and sent a (preliminary) patch which addresses some of the problems there. If you are interested, please watch that issue and reply to it.
In case someone who discussed the issue here is interested: patches went into Evolution 2.22.x (to be included in 2.22.3) and trunk today which solve the time zone issues around meeting invitations for the file and Exchange backend. The GroupWise backend still needs someone who can write a (hopefully simple) patch and test it; I don't have such an installation and therefore cannot do that. For the details see bug #528902 and for a summary this blog post: http://www.estamos.de/blog/2008/06/22/time-zone-handling-in-evolution/ I'm closing this bug now because it is considered resolved (as far as the original problem is concerned) resp. was superseded by #528902.