is anyone else getting duplicates of this message every few days? This has been going on for months and is a bit annoying. Is the mailing-list server looping or what?
Jeff On Thu, 2008-04-03 at 19:45 +0200, Patrick Ohly wrote: > 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. > > _______________________________________________ > Evolution-hackers mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/evolution-hackers _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
