http://bugs.meego.com/show_bug.cgi?id=6680
pohly <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|[email protected] |[email protected] --- Comment #12 from pohly <[email protected]> 2010-12-15 23:55:31 PST --- (In reply to comment #11) > Let me see whether I can change the TZID in SyncEvolution 1.1.1. I've changed in the libsynthesis which will be used in 1.1.1 and so far see no drawbacks. Ove, do you see a chance to update to that as the backend of your UI? commit 3d76d2399ba9312290375e8f97755b8db87628bf Author: Patrick Ohly <[email protected]> Date: Wed Dec 15 15:23:41 2010 +0100 Linux time zones: use TZID=<location> instead of TZID=/softwarestudio.org/Tzfile/<location> The shorter TZIDs will be included in iCalendar 2.0 data exported by libsyntesis. This change is motivated primarily by the observation that the N900 calendar storage can handle TZID=<location>, but not TZID=/softwarestudio.org/Tzfile/<location> (BMC #6680). It seems to do a literal comparison against its built-in time zone definitions and cannot handle definitions which have no match. The mKCal storage in MeeGo (N900 successor) can handle custom definitions, but also benefits from the change: TZID=<location> is mapped to the internal definitions, which are more complete (include transition dates for multiple years). A secondary benefit is slightly shorter item data in SyncML messages. The risk is that peers which depended on the TZID=/softwarestudio.org/Tzfile/<location> format break (fail to deal with definition) or become less efficient (have to fall back to custom time zone handling). There are no known peers with such a limitation. Untested peers which break completely were arguably already broken without this change. In practice, testing shows that at least the following peers are not affected at all: * Evolution calendar storage: my e_cal_match_location() is able to match TZID=<location> to the system time zones and thus Evolution continues to use the same time zone definitions as before. * Funambol itself already uses the shorter format and can receive it just fine. * An older SyncEvolution server with the unmodified time zone import code also maps to the imported definitions. -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
