[Evolution-hackers] cleaning up the timezone handling mess

[Patrick Ohly <Patrick Ohly gmx de>]

Hello,

did the slightly inflammatory subject catch your attention? Good, please
keep reading... ;-)

Details can be found in multiple Bugzilla entries, the most important
one apparently being this one:
http://bugzilla.gnome.org/show_bug.cgi?id=301363

Let me summarize the current situation: since 2.12, Evolution uses the
host's timezone information. This is only a partial solution. For events
created by other programs the incomplete and sometimes obsolete
VTIMEZONE information is still used.

As an example, take the two attached meeting invitations. The "2006" one
is a real stripped down invitation from Outlook, created in 2006 using
the old DST rules. The newer "2008" one uses the current rules.

When importing "2006" into a local calendar file, the "GMT -0600
(Standard) / GMT -0500 (Daylight)" timezone definition is added to the
calendar. When importing "2008", the timezone definition is not updated.
This has the effect that the new meeting is not displayed correctly in
the calendar. But replacing the timezone definition would not be correct
either, because it would break the mapping of past events of the old
event before the DST change in 2007.

This is a conceptual problem of how timezone definitions are handled:
they should be attached to events, not to calendars. The Itip formatter
plugin demonstrates that: it uses the timezone definition included in
the meeting invitation and correctly calculates the local times for both
events.

One could argue that the sending program is at fault: it could have used
a different TZID after changing the timezone definition. Alternatively
it could have sent a more complex VTIMEZONE which also includes the
historic rules. I believe both causes other problems in practice.
Speculating about it is futile anyway and won't change the meeting
invitations that Evolution has to deal with.

Besides, don't blame Outlook too much: Evolution >= 1.12 now does
exactly the same thing. For example, a meeting invitation now uses
"/softwarestudio.org/Tzfile/America/Los_Angeles" and only includes the
current rules for daylight saving transitions.

The "2006" event demonstrates another problem: the recurrences during
those weeks in 2007 and 2008 where old and new rules differ are not
calculated correctly.

A user of SyncEvolution and ScheduleWorld reported timezone issues here:
http://www.scheduleworld.com/jforum/posts/list/1543.page

In the ensuing discussion Mark Swanson from ScheduleWorld suggested that
all clients should use the same TZIDs to reference a complete local
Olsen database. I don't think that this is doable in all cases, but I
think Evolution should at least try it. Without further ado, here's my
proposal how importing events into Evolution should work. If you agree,
then I can try to create a patch.

For each TZID used in an event, Evolution should try to find the
corresponding system timezone via a fuzzy search. If the TZID already
follows the pseudo-standard set by the Olsen database, then the
comparison could be based on the local part, e.g. "America/Los_Angeles".
This solves the problem of importing events generated by ScheduleWorld
(which currently uses a /scheduleworld.com/<revision date>/ prefix and
thus is not mapped to system time zones).

If the TZID is in some other format (like the ones used by Outlook),
then a hard-coded table could do the mapping. This would solve the
problem with the "2006" example. This step is kind of ugly and optional:
I myself would argue that for such recurring meetings the sender is
responsible for sending an update with the current VTIMEZONE. In my
experience this really happened in many cases beginning of 2007.

If a match is found, then the event is stored with the original TZIDs
replaced by the matching system ones. The VTIMEZONE is discarded.

If no match is found, then the custom VTIMEZONE definition must be
stored in the calendar. I don't think that the EDS infrastructure should
be changed. It would break APIs and be a lot of work to implement, plus
it would store multiple redundant copies of identical VTIMEZONE
definitions, leading to worse performance.

What I suggest instead is the following scheme: check whether the
calendar already has a VTIMEZONE with a given TZID. If one is found,
check whether the timezone definition is really identical. If it is, all
is well. If not, then rename the new timezone by attaching " <number>".
Repeat the check and renaming until a 100% match is found or the
timezone can be stored without colliding with an existing timezone. Then
proceed with importing the event with renamed TZIDs.

I believe that this could be implemented without changing anything in
libecal. I could implement it as part of SyncEvolution, but that won't
solve the problem when Evolution itself imports events. A new API call
in libecal would be a better solution.

Before I proceed, let me ask: are there other plans to tackle the
problem? Is someone working on it? Similar questions in #301363 were not
answered.

Do you agree with the outlined plan in principle? If no-one else is
working on it and you agree, then I would describe the new API call in
more detail and see whether I can get it implemented. I would reuse the
same code in SyncEvolution in order to improve the situation with older
Evolution releases and to avoid depending on an extended libecal in the
binary releases.

What is the timeline for this? 2.22 is released; if this version is
picked up by distributions unpatched, then we are bound to run into the
same problems again end of 2008 and probably also 2009.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:GMT -0600 (Standard) / GMT -0500 (Daylight)
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=4;BYDAY=1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20060907T131935Z
DTSTART;TZID="GMT -0600 (Standard) / GMT -0500 (Daylight)":20060912T073000
SUMMARY:Weekly Phone Call
UID:040000008200E00074C5B7101A82E00800000000309E865A56D2C601000000000000000
 01000000066DB701609E60F4B9352E50A0E0F6334
DTEND;TZID="GMT -0600 (Standard) / GMT -0500 (Daylight)":20060912T080000
RRULE:FREQ=WEEKLY;UNTIL=20201229T133000Z;INTERVAL=1;BYDAY=TU;WKST=SU
SEQUENCE:0
PRIORITY:5
CREATED:20060907T131935Z
LAST-MODIFIED:20060907T132254Z
STATUS:CONFIRMED
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:GMT -0600 (Standard) / GMT -0500 (Daylight)
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20080320T114812Z
DTSTART;TZID="GMT -0600 (Standard) / GMT -0500 (Daylight)":20080325T073000
SUMMARY:One Time Meeting
UID:040000008200E00074C5B7101A82E00800000000808C1CEBC5ACC701000000000000000
 0100000004F43682C84AEE84A8399EB29FF07BA7C
DTEND;TZID="GMT -0600 (Standard) / GMT -0500 (Daylight)":20080325T080000
SEQUENCE:0
PRIORITY:5
CREATED:20080320T114811Z
LAST-MODIFIED:20080320T114816Z
STATUS:CONFIRMED
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR