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 -- [EMAIL PROTECTED] 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
_______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
