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

[Patrick Ohly <Patrick Ohly gmx de>]

On Tue, 2008-04-15 at 13:59 +0530, chenthill wrote: 
> To preserve the timezone history, the best way would be to store the old
> rules in VTIMEZONES which should be done in libical.

If I understand you correctly, you are suggesting to merge a VTIMEZONE
with TZID=FOO that comes with a new meeting invitation with a previously
stored VTIMEZONE with the same TZID, so that the merged VTIMEZONE has
the rules from both the original VTIMEZONE.

The problem is that incoming VTIMEZONE definitions from Exchange do not
contain information to which year the rules apply. In the examples that
I quoted, both use DTSTART:16010101T020000 and thus are mutually
exclusive.

> 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.

I don't get this part. Can you elaborate what you mean? Are you saying
that storing a VTIMEZONE with TZID=FOO as TZID=FOO 2 when it conflicts
with an existing VTIMEZONE should be avoided?

>  Once the
> outlook timezones are mapped with libical ones, the libical timezones
> which would have the old rules can be used.

Mapping "foreign" TZIDs to system timezones always should be attempted
first. Storing a VTIMEZONE under a different name is only the fallback.

> > [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.

SyncEvolution is not a backend. It is a client program using the
synchronous libecal API.

I believe OpenSync works the same way, although I haven't looked at it
during the last two years.

>  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?

No, because the call cannot return the information to which TZID the
timezone was mapped. Modifying the "icaltimezone *zone" would be an API
change.

> 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.

I'll create a new bug report. Should we move the discussion away from
this list?

Usually we could meet on IRC during the evening CEST, but there's not
much time this week.

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