Description of problem: The calendar files attached to invitations (meeting.ics og calendar.isc in case of Outlook 2003/2007 clients) are interpreted incorrectly, so the displayed times are one hour off compared to the actual times. I'm pretty sure this has something to do with the way evolution understands my timezone (which is WGST/WGT (America/Godthab), set on both my system and in evolution), since this problem has only showed itself in the past week or so. Daylight savings changes this coming sunday, here. The same calendar files work fine when imported into thunderbird/lightning and it appears as though the alarms actually notifies me at the correct time??? I'm not sure - it could have been a one-off glitch, but I thought the info might help you narrow down the problem. Version-Release number of selected component (if applicable): evolution-2.22.3.1-1.fc9.i386 How reproducible: Always Steps to Reproduce: 1. In a WGST environment (possibly close to DST change) view an invitation sent from another client 2. Notice that the times shown are one hour off Actual results: Times are one hour off Expected results: Times should be correct at any time Additional info:
Created attachment 321274 [details] sample ical file that shows this problem in my client
Created attachment 321275 [details] screenshot of how the calender file is interpreted
Sounds similar to bug #467912
There seems to be something wrong with the timezone component stored in the file. Yours says: BEGIN:VTIMEZONE TZID:(GMT-03.00) Greenland X-MICROSOFT-CDO-TZID:60 BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0200 TZOFFSETTO:-0300 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0300 TZOFFSETTO:-0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=4;BYDAY=1SU END:DAYLIGHT END:VTIMEZONE But the similar evolution's is: BEGIN:VTIMEZONE TZID:(GMT-03.00) Greenland BEGIN:STANDARD TZNAME:WGT DTSTART:19701024T220000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-2SA;BYMONTH=10 TZOFFSETFROM:-0200 TZOFFSETTO:-0300 END:STANDARD BEGIN:DAYLIGHT TZNAME:WGST DTSTART:19700328T230000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SA;BYMONTH=3 TZOFFSETFROM:-0300 TZOFFSETTO:-0200 END:DAYLIGHT END:VTIMEZONE See lines beginning with the DTSTART, the Evolution's one seems to be more correct than one sent from the Outlook. The lightning, hmm, maybe I've old version (thunderbird-lightning-0.8-3.fc9.x86_64) or I do not understand it enough, but with these tests it seems it's not behaving correctly either. a) I moved start and end of the appointment to October 30th, left there the broken VTIMEZONE. They imported it with exactly same time. b) I changed timezone information in the file with that from Evolution, and imported file with October 23rd and 30th. The first has moved time to 17-18 in the UI, the later has the same time as before. So I think they apply the time zone shift even they should not, and further more, they just ignore broken timezone information in the file. (Just observation, no clues on that.) I'll try to catch upstream calendar developer and ask him for his thoughts. He will probably correct the above information.
Hi there... I'm not entirely sure how to read the DTSTART entries, but I'll give you a pointer to the proper definition of start/end of daylight savings time here in West Greenland: DST begins on (y is the year): Sunday (31 - (5y ÷ 4 + 4) mod 7) March at 01.00 GMT DST ends on (y is the year): Sunday (31 - (5y ÷ 4 + 1) mod 7) October at 01.00 GMT (from http://en.wikipedia.org/wiki/European_Summer_Time) I'll be looking forward to see what upstream has to say. Thanks a lot so far.
Oh, I'm sorry, it's a date and time in a format YYYYMMDDTHHMMSS where the 'T' is only separator. I sent mail to the upstream developer, hoping in a soon response.
I got the reply from upstream developer and he said it should be fine until the fix in an upstream bug [1]. The version 2.22.3.2 of Evolution-Data-Server doesn't contain that fix. The bad thing is I see this even with actual trunk, where is the fix included. I'll discuss this with them in the upstream bug, and close this one, thus feel free to add yourself to that bug to receive changes. And thanks for your help. [1] http://bugzilla.gnome.org/show_bug.cgi?id=548268
I got a response in the upstream bug, it seems it's a known issue and limitation of the library Evolution is using, with some other things too. See this for more information: http://bugzilla.gnome.org/show_bug.cgi?id=548268#c22