GNOME Bugzilla – Bug 220076
iTIP requests from Outlook result in mangled TZIDs
Last modified: 2013-09-10 14:02:48 UTC
On Wed, 2002-02-06 at 09:57, Jan Mynarik wrote: > Hi, > > I've received attached vCalendar file from Outlook2000 user and accepted > it without sending the confirmation of invitation. Evolution said > something like 'update complete' but if I go to calendar, there is no > meeting visible. But on the day number (where the meeting should be) is > bold in the small calendar in upper right corner. I tried to delete my > whole calendar (evolution/local/Calendar) and to apply the vCalendar > again but with the same result. > > What's wrong? I'm using Evolution 1.0.2 from Debian Sid(unstable). Evolution changed the TZID from: TZID:Belgrade, Bratislava, Budapest, Ljubljana, Prague to: TZID:Belgrade TZID: Bratislava TZID: Budapest TZID: Ljubljana TZID: Prague When Evolution tries to convert the event times to display in the calendar it won't be able to find the right timezone so it will skip the event. I think the problem is probably in libical, since I don't think Evolution touches the TZID string. And it seems to occur as soon as the object is added to the calendar, i.e. I don't think its a problem when loading the file.
Setting to 1.2 as it could be a major interop problem with Outlook.
What SR of Outlook 2000 was being used? Basically the commas in the tzid broke the icalendar spec and microsoft has changed the separator in atleast Outlook 2000 SR-1.
Is there any way we can verify that Outlook 2000 (with the latest Service Pack) no longer does that?
i do not believe this is reproducible in evo 1.1.2 (or possible outlook 2002/xp). created mtg invite in outlook2002 with timezone setting of TZID:Belgrade, Bratislava, Budapest, Ljubljana, Prague. Sent to IMAP accout & opened using Evo. View source in Evo, see TZID as above. Viewed Accepted response in Sent folder, also see TZID same as above. Not seeing a bug. if needs reproducing in other way, please let me know (also downgraded to Normal)
Tried to reproduce this in 1.2 to no avail. Closing as fixed. If anyone can reproduce in 1.2 or later, please open a new report.