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 -- [EMAIL PROTECTED] http://www.estamos.de/ _______________________________________________ Evolution-hackers mailing list Evolutionfirstname.lastname@example.org http://mail.gnome.org/mailman/listinfo/evolution-hackers