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