---- Reported by jingke.zhang@intel.com 2010-04-14 02:37:46 +0000 ----

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?



---- Additional Comments From jingke.zhang@intel.com 2010-04-14 02:39:30 +0000 ----

There are too many attachment (calendar data) in the original bug. Please refer old link: http://bugzilla.moblin.org/show_bug.cgi?id=4815
Thanks!



--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

This bug was previously known as _bug_ 762 at https://bugs.meego.com/show_bug.cgi?id=762