[Syncevolution-issues] [Bug 762] New: Outlook meeting invitations: timezones

http://bugzilla.meego.com/show_bug.cgi?id=762 Summary: Outlook meeting invitations: timezones Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: All OS/Version: IA Status: NEW Severity: enhancement Priority: Medium Component: SyncEvolution AssignedTo: syncevolution-bugs(a)meego.bugs ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Estimated Hours: 0.0 This bug is from http://bugzilla.moblin.org/show_bug.cgi?id=4815 Description From pohly 2009-07-28 06:00:35 PST (-) [reply] This was originally found when syncing an Evolution calendar with a meeting invitation created by Outlook with ScheduleWorld. Outlook's VTIMEZONE definitions are nasty because the ID is not unique enough to identify the location. Software that supports VTIMEZONE to evaluate the times doesn't have a problem, as long as it handles different VTIMEZONE definitions for the same ID correctly (Evolution had a bug around that). Many servers, including ScheduleWorld and Funambol, have to map the VTIMEZONE to some internal time zone database because they cannot use the original definition, or because they need to send to a client which doesn't. This mapping is fragile and unreliable if the ID doesn't follow the Olson pseudo-standard and contains the location. In my case, "TZID:Pacific Standard Time" was mapped to "America/Bogota", presumably because the GMT offsets kind of matched. It then was displayed incorrectly. A client shouldn't have to deal with these issues. But because we are now working towards implementing a server, we need this kind of mapping code ourselves and once we have it, might as well use it in our client. The goal is that the client always uses Olson TZID strings when talking to a SyncML server. That way we have that timezone matching code under our control and can tune and/or fix it. Right now we depend on server developers to do it for us. The Synthesis timezone handling code doesn't do that for us quite yet. It does match based on Olson TZID if libical is found, so those TZIDs are covered. For Outlook TZIDs it falls back to matching against an internal list, without using Olson TZID strings for those if a match is found. We should change that so that the list has TZID aliases with the Olson name and use those names when encoding a VTIMEZONE. Not sure whether this change is acceptable upstream; need to discuss and perhaps make it configurable. If no match is found, then a temporary time zone definition is used, but it is not preserved in the database unless the database stores VTIMEZONEs. In other words, Evolution is fine, the ODBC backend is not. If we use the later in a server, we need to fix this issue. I can dig out the example, but we need more than one anyway. Ideally we need examples for the whole range of Outlook and Exchange (they can be different!) VTIMEZONE definitions, extend out test suite to cover the conversion, then work on correctly identifying all these timezones. ------- Comment #1 From pohly 2010-01-31 23:55:58 PST (-) [reply] ------- Raji, you were working on this. What's the current status and what next steps do you suggest? -- Configure bugmail: http://bugzilla.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.