Re: [Evolution-hackers] cleaning up the timezone handling mess
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:16010101T02 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.
Re: [Evolution-hackers] cleaning up the timezone handling mess
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=1912252forum_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 -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] cleaning up the timezone handling mess
On Wed, Apr 16, 2008 at 10:00 PM, Patrick Ohly [EMAIL PROTECTED] wrote: On Wed, 2008-04-16 at 13:59 +0530, chenthill palanisamy wrote: 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. Very true.. it was/is a serious PITA while I was figuring out the details for the MAPI provider. On the brighter side, Exchange/Outlook 2007 has got this sorted out to an extent. They now store the historical rules in the timezone blob. See [1]. (The MAPI provider does not yet makes use of these rules, it only identifies the timezone - maps it to one of the system timezones - then uses the system timezone information to generate the start-end times of the event.. its a todo on my list to make use of the stored information :-) ) And, like you have mentioned, the mapping needs constant maintenance despite publications like [2] or [3] :-( -Suman [1] http://blogs.msdn.com/stephen_griffin/archive/2006/12/06/outlook-2007-timezone-structures.aspx [2] http://msdn2.microsoft.com/en-us/library/ms912053.aspx [3] http://technet2.microsoft.com/WindowsVista/en/library/31f49a21-cfed-4b63-b420-58a9eabbb04e1033.mspx?mfr=true ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
