Bug 468168

Summary: meeting (.ics) times are not interpreted correctly
Product: [Fedora] Fedora Reporter: Thomas M Steenholdt <tmus>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-12 11:05:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
sample ical file that shows this problem in my client
none
screenshot of how the calender file is interpreted none

Description Thomas M Steenholdt 2008-10-23 12:26:58 UTC 
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:
Comment 1 Thomas M Steenholdt 2008-10-23 12:28:34 UTC 
Created attachment 321274 [details]
sample ical file that shows this problem in my client
Comment 2 Thomas M Steenholdt 2008-10-23 12:29:18 UTC 
Created attachment 321275 [details]
screenshot of how the calender file is interpreted
Comment 3 Milan Crha 2008-10-31 20:37:24 UTC 
Sounds similar to bug #467912
Comment 4 Milan Crha 2008-11-05 14:49:15 UTC 
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.
Comment 5 Thomas M Steenholdt 2008-11-05 17:46:13 UTC 
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.
Comment 6 Milan Crha 2008-11-05 19:19:37 UTC 
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.
Comment 7 Milan Crha 2008-11-12 11:05:29 UTC 
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
Comment 8 Milan Crha 2008-11-18 12:03:06 UTC 
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