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

[chenthill <pchenthill novell com>]

On Fri, 2008-04-11 at 23:31 +0200, Patrick Ohly wrote:
> On Fri, 2008-04-11 at 00:55 -0600, P Chenthill wrote:
> [Exchange calendar backend patch]
> > In cases of exchange the old VTIMEZONE and the new VTIMEZONE would have
> > the same tzid, only the rules would be different. All events old and new
> > will just use the latest timezone from the backend since they would have
> > the same tzid in their start/end dates.
> 
> And that would be wrong for the old events which are truly in the past.
> Consider the 2006 example that I sent: when viewing the year 2006 in the
> calendar, the system timezone definition is used and thus Evolution
> correctly uses the summer saving rules from 2006. Using the updated
> VTIMEZONE for events in that year would lead to a one hour shift during
> those weeks where old and new rules differ.
> 
> It's arguably the lesser evil for recurring events because the current,
> still relevant recurrences would be displayed correctly, so there is
> some value in it. But for old events which are archived for reference
> purposes it would be just wrong. What I am suggesting would solve this
> problem by preserving both the old and the new VTIMEZONE.
> 
> For recurring events the mapping to the more complex system timezone
> definitions helps.
To preserve the timezone history, the best way would be to store the old
rules in VTIMEZONES which should be done in libical. Since exchange does
not like it, the older rules should be stripped off while sending the
timezones to the exchange server at the backend and libical should
facilitate this. I do not recommend having another set of tzid's with
versions in it for maintaining the old rules. This would trigger the
comparison of rules between different versions of timezones. Once the
outlook timezones are mapped with libical ones, the libical timezones
which would have the old rules can be used.

> 
> [VTIMEZONE and VEVENT are added separately]
> > I don't think it works like that. iirc the whole VCALENDAR (used as
> > top-level component in itip-formatter) which has events and timezone
> > gets passed to the backend, the backend adds the timezone and events to
> > the cache, notifies the UI.
> 
> After looking at the Evolution source code I already came to the same
> conclusion. However, clients like SyncEvolution do add VTIMEZONE and
> VEVENT separately. That is necessary because the UID of each new VEVENT
> is required immediately, which is not possible (or at least very
> awkward) via ecal_receive_objects().
I hope SyncEvolution is the only backend which does it in this way. I am
not sure if we would need a libecal API for this. Is it not possible to
handle it inside e_cal_backend_add_timezone ? I don't know much about
how SyncEvolution handles it. While considering with all the other
backend's in mind which are under EDS, exchange, I don't feel the need.

> 
> This makes the new function a bit more compleyoutube.com/TuxSkyNetx, but I still think it is
> doable to come up with a solution which can be used by backends and
> clients. Attached is a proposal. In SyncEvolution I would lookup
> existing VTIMEZONE in the calendar via the e_cal_tzlookup_ecal() utility
> function, which then uses e_cal_get_timezone(). 
>                               
> I checked the code of the file backend. The e_cal_check_timezone() call
> would fit right before the icalcomponent_merge_component() call and
> would use the other tzlookup function which checks against local
> VTIMEZONE components.
> 
> All the other backends would have to be adapted in a similar way. I
> considered modifying the general e_cal_backend_file_receive_objects(),
> but decided against it because individual backends might have better
> ways of dealing with the problem. I also don't want to touch code which
> I cannot test.
> 
> I will be out of town for three days. If there are no objections, then
> I'll try to get working code together when I come back, hopefully before
> I go on a business trip for two weeks the week after. Time, anyone got
> some time?
Yeah you can get the code after two weeks, not a problem. Please file a
bug on this since the old bug is about, outdated evolution timezones
which is obsolete now as we pickup the timezones from the system. The
bug also has a too many comments already. Probably we can also schedule
a meeting on irc and have a discussion on this. Please let me know the
time which would be suitable for you.

thanks, Chenthill.