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

[Patrick Ohly <Patrick Ohly gmx de>]

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?

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

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

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

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