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

[Patrick Ohly <Patrick Ohly gmx de>]

On Wed, 2008-04-16 at 13:59 +0530, chenthill palanisamy wrote:
> 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.

Wow, in that case the situation is much worse than I thought. My
impression was that the patch to use system timezone definitions would
solve the problem of using out-dated, incomplete timezone definitions
shipped with Evolution. The truth is that it only eases the maintenance
pain regarding out-dated definitions, but doesn't address the "timezones
change over time" problem at all, right?

If this was a known limitation, why was it not already filed as bug a
long time ago? Evolution users running into timezone problems were
instead told to update to the latest Evolution release and update their
system timezone definitions, which in many cases didn't help at all.

> 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 agree that libical absolutely must use the complete timezone history
stored on the system. This is independent from mapping "foreign" TZIDs
to native ones; both is necessary, but can be implemented separately. Do
you have an estimate how much work improvements for libical would be?
Where are the places which have to be changed? How can we distinguish
between extracting a VTIMEZONE which is to be sent to some other program
and extracting a VTIMEZONE for internal use?

Finally, one organizational question: should a patch be prepared against
the libical in the GNOME or the SF repository? According to this post,
the SF repository is trying to consolidate the various versions floating
around:
http://sourceforge.net/forum/forum.php?thread_id=1912252&forum_id=51011

How does the Evolution team stand with regards to that effort?

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

You assume that the mapping works in all cases. I don't think this is
realistic. There will always be a program FOO somewhere, somewhen using
a TZID=BAR which is unknown to Evolution and thus cannot be mapped. Even
getting this right just for Outlook alone will be challenging and
require permanent maintenance.

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

Have a look at http://www.estamos.de/projects/SyncML/index.html -
calling a SyncML server that VEVENTs are exchanged with "external
backend" kind of fits, but not quite.

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

This fails to handle VTIMEZONE definition collisions in those cases
where no mapping to system timezones is found. In that case the
VTIMEZONE needs to be stored with a different TZID and the VEVENT needs
to be patched.

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