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

[chenthill palanisamy <pchenthill novell com>]

On Tue, 2008-04-15 at 18:07 +0200, Patrick Ohly wrote:
> 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.
Nope I don't mean merging here. The VTIMEZONE from libical currently do
not provide the history of timezone changes (older + current rrules) for
the system timezones. Libical should be modified so that the VTIMEZONE's
generated stores the timezone history. The Tzfile would have the history
stored on the system, libical just does not store it in VTIMEZONE.


Say if a meeting is received from exchange server with some Tzid for
America/New_York. As we discussed below, this needs to be mapped to
system timezone and libical should provide the VTIMEZONE which has the
timezone history.  This way, we need not use the VTIMEZONE sent by
exchange and still display the older/current events properly.

> 
> > 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?
yes, if  libical is modified to return VTIMEZONE with the history and
once mapping between "foreign" timezones to system timezones is done at
the backend, this is would not be required. All the older events would
be properly displayed.

> 
> >  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.
Ah ok. I misunderstood that it has a corresponding external backend as
well.

> 
> 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.
The tzid need not be changed for the VEVENT. The following would work
fine even if VTIMEZONE and VEVENT are handled separately,

e_cal_backend_add_timezone - Add the timezone to backend's cache if the
timezone cannot be matched with the system timezone else do not add.

e_cal_backend_get_timezone - use the mapping and provide proper system
timezone or if its unable to map, it needs to get the timezone from the
cache.

The clients can now use the corresponding libecal API's to get the right
timezone. So, I feel this can be done commonly to all backends at EDS.

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

I think if we discuss this on IRC, we can conclude on the design
faster. It would be better to do the patch reviews in bugzilla.

> 
> Usually we could meet on IRC during the evening CEST, but there's not
> much time this week.
I may not be available over next week. Let me know a suitable time
during this week or after April 28th.

- Chenthill.