Re: [Evolution-hackers] cleaning up the timezone handling mess

[Jeffrey Stedfast <fejj novell com>]

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
> Evolution-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers