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

["P Chenthill" <pchenthill novell com>]

On Wed, 2008-04-09 at 00:42 +0200, Patrick Ohly wrote:
> On Mo, 2008-04-07 at 23:40 -0600, P Chenthill wrote:
> > On Thu, 2008-04-03 at 19:45 +0200, Patrick Ohly wrote:
> > > 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.
> > It just includes the current rules for outlook compatibility.
> 
> Yep, that's the "I believe both causes other problems in practice"
> part ;-)

> 
> > I am just back after a small vacation.
> 
> Ah, that explains the silence. I'll be away over the weekend and Monday
> myself and don't know whether I'll have time before I came back.
> 
> > I dont think anyone is work on this issue currently. I made a patch for
> > exchange backend for solving this issue long time back. But
> > unfortunately its not committed in trunk.
> 
> Why? Technical issues that I should be aware of?
I think it was postponed to commit after some freeze and missed later. I don remember
the exact reasons. I am sure, its not due to any technical reasons :-)


> >  It uses a timestamp in the
> > VTIMEZONE file to store the latest one always. By this way we would also
> > know the last time period when the timezone has been changed for that
> > location.
> 
> I can't claim to understand the patch or the code that it applies to.
> When you say that only the latest VTIMEZONE is stored, that implies that
> only one is stored, right? How does that solve the problem of having an
> event in the calendar which depends on an old revision of the VTIMEZONE
> and another one which needs the current revision?
The cache would have only one version of the timezone at any point since
the tzid is used as a uid for the VTIMEZONE components for storing them.
The X-EVOLUTION-TZ-TIMESTAMP would be used to ensure that only the
latest VTIMEZONE is stored. Since the UI would pick the timezone from
the backend, it would get the right timezone.

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.

> 
> > I am ok with handling using the sequence numbers. I am not sure whether
> > a new libecal API would be needed to solve this, since the timezones
> > would be handled at the backend.
> 
> The client adds the VTIMEZONE and some time later the corresponding
> event. At that time the backend won't be able to correlate the two, but
> that is necessary to change the TZID in the event if the VTIMEZONE was
> stored with a different TZID. Only the client can do that.
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. This is the same behavior while accepting
and importing events. Another reason why this has to be handled in
backend is, there can be cases when the user can accept events using
some other client and receive the events through the respective
backends. So handling it in the backend would be better. Atleast above
is the behavior w.r.t exchange, and other backends under EDS.

> 
> > It would be better to handle all the timezones in a common place inside
> > EDS. The reason for that is, same timezones can exist in multiple
> > calendars which could not be matched to either system timezone or
> > through the fuzzy logic. Currently it is handled separately for every
> > calendar and the same information is stored redundantly. Another issue
> > which should be taken care of is, the system timezones should not be
> > stored in the cache. They should always be taken from the libical
> > builtin timezone. Please consider these too while implementing the
> > solution.
> 
> That's way beyond what I have time for, sorry. Besides, I want to keep
> my changes as small as possible to increase the chance of getting them
> into the stable branch.

- Chenthill.