After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 301363 - Evolutions timezone data is seriously incomplete and out-of-date
Evolutions timezone data is seriously incomplete and out-of-date
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Calendar
1.2.x (obsolete)
Other All
: High major
: ---
Assigned To: Chenthill P
Evolution QA team
: 300606 392170 416160 417885 417936 418074 418323 418720 423102 433953 523274 (view as bug list)
Depends on:
Blocks: 327516
 
 
Reported: 2005-04-20 16:59 UTC by Roozbeh Pournader
Modified: 2013-09-10 13:42 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
proper timezone for Asia/Tehran (cutting at 1970) (3.11 KB, text/plain)
2005-04-25 09:37 UTC, Roozbeh Pournader
  Details
proper timezone for America/Los_Angeles (cutting at 1970) (1.08 KB, text/plain)
2005-04-25 09:39 UTC, Roozbeh Pournader
  Details
proper timezone for Asia/Jerusalem (cutting at 1970) (2.89 KB, text/plain)
2005-04-25 09:44 UTC, Roozbeh Pournader
  Details
Fixes the bug. (77.62 KB, patch)
2007-01-23 10:50 UTC, Chenthill P
none Details | Review
Updated timezones. (76.88 KB, patch)
2007-03-05 11:24 UTC, Chenthill P
committed Details | Review
updated America/New_York.ics file with additional DAYLIGHT/STANDARD sections (780 bytes, text/plain)
2007-03-14 20:02 UTC, Bret Whissel
  Details

Description Roozbeh Pournader 2005-04-20 16:59:37 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).
Comment 1 Roozbeh Pournader 2005-04-20 17:27:07 UTC
From what I can see in the sources, it should be a problem in data files of libical.
Comment 2 Roozbeh Pournader 2005-04-21 09:12:22 UTC
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).
Comment 3 Roozbeh Pournader 2005-04-25 09:37:47 UTC
Created attachment 45638 [details]
proper timezone for Asia/Tehran (cutting at 1970)
Comment 4 Roozbeh Pournader 2005-04-25 09:39:25 UTC
Created attachment 45639 [details]
proper timezone for America/Los_Angeles (cutting at 1970)
Comment 5 Roozbeh Pournader 2005-04-25 09:44:05 UTC
Created attachment 45640 [details]
proper timezone for Asia/Jerusalem (cutting at 1970)
Comment 6 Roozbeh Pournader 2005-04-25 09:46:58 UTC
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.
Comment 7 Roozbeh Pournader 2005-04-25 09:59:28 UTC
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...
Comment 8 Sushma Rai 2005-04-26 06:03:06 UTC
Sarfraaz?
Comment 9 Harish Krishnaswamy 2005-08-13 10:47:45 UTC
Chen/Sarfraaz : could you please test this out ?
Comment 10 Roozbeh Pournader 2005-08-18 15:39:04 UTC
Bug 300603 may be a duplicate of this.
Comment 11 Roozbeh Pournader 2005-08-18 15:39:34 UTC
Oops, I meant Bug 300606 may be duplicate of this.
Comment 12 André Klapper 2005-09-28 12:04:52 UTC
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.
Comment 13 Chenthill P 2005-12-21 12:43:41 UTC
*** Bug 300606 has been marked as a duplicate of this bug. ***
Comment 14 Heikki Henriksen 2006-04-06 12:37:59 UTC
According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360981
America/Indiana/* needs an update as well.
Comment 15 Roozbeh Pournader 2006-04-12 14:00:52 UTC
Doesn't block 311332 anymore, since Iran has cancelled daylight saving.
Comment 16 André Klapper 2006-05-22 11:30:41 UTC
chen/sarfraaz: ping?
Comment 17 Chenthill P 2006-06-06 04:57:00 UTC
Looking into it.
Comment 18 André Klapper 2006-06-15 13:37:10 UTC
removing old target milestone, setting new one.
Comment 19 André Klapper 2006-06-15 13:47:23 UTC
reassigning bugs assigned to dinesh layek to avoid rotting.
Comment 20 André Klapper 2006-08-12 11:57:55 UTC
chen: poke!
this is even more important as bug 349078.
Comment 21 Chenthill P 2006-08-28 18:19:55 UTC
Updated the timezone information for Jerusalem and Los_Angeles.
Comment 22 Matthias Clasen 2006-09-20 05:24:19 UTC
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
Comment 23 Matthew Barnes 2006-09-20 19:04:40 UTC
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.
Comment 24 Chenthill P 2006-09-21 10:21:03 UTC
Oh, the two files committed were the same. Updated the right file for Jersusalem.
Comment 25 Kjartan Maraas 2007-01-17 00:23:38 UTC
Can we close this then?
Comment 26 Chenthill P 2007-01-23 10:50:24 UTC
Created attachment 80963 [details] [review]
Fixes the bug.
Comment 27 Chenthill P 2007-01-23 10:58:53 UTC
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.
Comment 28 Roozbeh Pournader 2007-01-23 11:07:51 UTC
(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.
Comment 29 Matthias Clasen 2007-01-23 14:41:05 UTC
If evolution would just use tzdata, this whole problem would not occur.
Comment 30 Chenthill P 2007-01-24 10:28:50 UTC
(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. 
Comment 31 Roozbeh Pournader 2007-01-24 10:43:19 UTC
(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.
Comment 32 Chenthill P 2007-01-24 11:05:31 UTC
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.
Comment 33 Chenthill P 2007-01-24 11:13:24 UTC
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.
Comment 34 Matthias Clasen 2007-01-24 12:44:37 UTC
Roozbeh is right. I was suggesting that it is suboptimal to have 2 redundant 
sources of timezone information in the system. 
Comment 35 Jeff Cai 2007-03-01 07:56:30 UTC
When will the patch be committed? you know that March 11, the daylight time will begin.
Comment 36 Chenthill P 2007-03-05 11:19:59 UTC
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.
Comment 37 Chenthill P 2007-03-05 11:24:47 UTC
Created attachment 83954 [details] [review]
Updated timezones.
Comment 38 Chenthill P 2007-03-05 11:43:41 UTC
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 :-).
Comment 39 Chenthill P 2007-03-05 11:51:20 UTC
*** Bug 392170 has been marked as a duplicate of this bug. ***
Comment 40 Harry Lu 2007-03-05 12:48:43 UTC
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.
Comment 41 Harish Krishnaswamy 2007-03-05 13:35:01 UTC
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.
Comment 42 Chenthill P 2007-03-05 18:57:22 UTC
Fix has been committed to svn HEAD and stable branch.
Comment 43 Matthew Barnes 2007-03-05 19:31:54 UTC
Is there another stable update planned which will include these changes or is it up to the distros?
Comment 44 Ole Craig 2007-03-08 22:51:51 UTC
(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.
Comment 45 daniel 2007-03-09 04:46:57 UTC
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."
Comment 46 André Klapper 2007-03-09 17:04:23 UTC
*** Bug 416160 has been marked as a duplicate of this bug. ***
Comment 47 Chris Weber 2007-03-12 17:39:11 UTC
(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.
Comment 48 Chris Weber 2007-03-12 18:21:45 UTC
(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
Comment 49 Ole Craig 2007-03-13 00:51:54 UTC
> 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?
Comment 50 Chenthill P 2007-03-13 11:25:55 UTC
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 ?
Comment 51 Chris Weber 2007-03-13 11:49:30 UTC
(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.
Comment 52 Chris Weber 2007-03-13 14:35:43 UTC
(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. 
Comment 53 madcap 2007-03-13 14:41:19 UTC
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.
Comment 54 jslavin 2007-03-13 15:31:53 UTC
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?
Comment 55 madcap 2007-03-13 16:51:53 UTC
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).
Comment 56 Alex deVries 2007-03-13 17:28:58 UTC
Is there a script that could do this conversion?  I have dozens of meeting invites that I'd have to move manually.

- A
Comment 57 Ole Craig 2007-03-13 18:09:13 UTC
(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
Comment 58 madcap 2007-03-13 19:56:17 UTC
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.
Comment 59 madcap 2007-03-13 20:06:11 UTC
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.
Comment 60 Bret Whissel 2007-03-14 20:02:06 UTC
Created attachment 84600 [details]
updated America/New_York.ics file with additional DAYLIGHT/STANDARD sections
Comment 61 Bret Whissel 2007-03-14 20:09:45 UTC
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.
Comment 62 André Klapper 2007-03-14 21:32:37 UTC
*** Bug 418323 has been marked as a duplicate of this bug. ***
Comment 63 Ole Craig 2007-03-15 01:18:48 UTC
(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!
Comment 64 Russell Harrison 2007-03-16 03:53:53 UTC
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?
Comment 65 André Klapper 2007-03-17 19:51:19 UTC
*** Bug 418074 has been marked as a duplicate of this bug. ***
Comment 66 André Klapper 2007-03-17 19:54:29 UTC
*** Bug 417936 has been marked as a duplicate of this bug. ***
Comment 67 André Klapper 2007-03-17 19:57:45 UTC
*** Bug 417885 has been marked as a duplicate of this bug. ***
Comment 68 Trevin Beattie 2007-03-19 20:46:20 UTC
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).
Comment 69 André Klapper 2007-04-01 14:45:02 UTC
*** Bug 418720 has been marked as a duplicate of this bug. ***
Comment 70 André Klapper 2007-04-12 20:18:44 UTC
*** Bug 423102 has been marked as a duplicate of this bug. ***
Comment 71 André Klapper 2007-04-30 12:13:18 UTC
*** Bug 433953 has been marked as a duplicate of this bug. ***
Comment 72 Paul Smith 2007-10-29 22:06:22 UTC
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!
Comment 73 C de-Avillez 2007-12-28 00:40:15 UTC
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.
Comment 74 Matthew Barnes 2007-12-28 02:51:16 UTC
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.
Comment 75 Trevin Beattie 2008-03-18 16:51:42 UTC
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.
Comment 76 Matthew Barnes 2008-03-18 17:41:59 UTC
The problem is likely because the old timezone data is embedded in the meeting itself.  That's iCalendar for ya.
Comment 77 Trevin Beattie 2008-03-18 18:08:33 UTC
Just where in the above ICS file do you see old timezone data?
Comment 78 madcap 2008-03-18 18:23:27 UTC
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.
Comment 79 Trevin Beattie 2008-03-18 20:19:43 UTC
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?
Comment 80 madcap 2008-03-18 20:56:26 UTC
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.
Comment 81 André Klapper 2008-03-19 10:49:42 UTC
*** Bug 523274 has been marked as a duplicate of this bug. ***
Comment 82 Patrick Ohly 2008-04-19 13:44:08 UTC
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.
Comment 83 Patrick Ohly 2008-06-22 15:57:03 UTC
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.