http://bugs.meego.com/show_bug.cgi?id=9600
--- Comment #3 from pohly <[email protected]> 2010-12-13 00:00:04 PST --- (In reply to comment #2) > There's a bug (?) in vtimezone.cpp/ContextToTzDaylight(): it assumes that > t.name is of the format <foo>/<bar> where <foo> and <bar> are names without > slashes which stand for summer and winter time (CEST/CET). > > This is not the case for time zones imported by > platform_timezones.cpp/finalizeSystemZoneDefinitions(). They put the original > TZID into t.name. I've changed libsynthesis to avoid this: commit 29a7998a0e27d3a664b3ca143baf201b72ecdc6a Author: Patrick Ohly <[email protected]> Date: Sun Dec 12 21:36:10 2010 +0100 vtimezone: retain original TZID in imported definitions VTIMEZONEtoInternal() used to overwrite the original TZID because there was no other place to store standard and daylight saving TZNAME. Since there are now explicit fields for that, the code overwriting the TZID can be removed. The advantage is that importing and exporting a custom definition introduces less changes, because now the original TZID will be exported. commit d9f9af69176d776d09f99d85789973fd5d3b10f4 Author: Patrick Ohly <[email protected]> Date: Sun Dec 12 21:19:16 2010 +0100 vtimezones: explicitly store std and dst TZNAME In vCalendar 1.0, the DAYLIGHT property must list standard and daylight saving zone names, for example CET;CEST. ContextToTzDaylight() used to extract these two names from the tz_entry::name field. This was rather implicit and not documented, so the Linux timezone import code got it wrong and stored the original TZID (like /freeassociation.sourceforge.net/Tzfile/Australia/Melbourne), leading to an invalid DAYLIGHT property with too many components. Such an entry is accepted by Nokia phones in an ADD, but not an UPDATE (bugs.meego.com #9600). The code would also have failed for a (hypothetical) VTTIMEZONE definition with TZNAMEs that contain slashes. To make the code more robust and easier to understand, this patch introduces explicit dstName and stdName fields in tz_entry. VTIMEZONEtoTZEntry() sets them directly, thus allowing the removal of two parameters in that function. ContextToTzDaylight() still falls back to splitting the tz_entry::name field if dstName or stdName are not set when needed, so these new fields are strictly optional. In particular the code which creates tz_entry from the builtin table can work as before. The code which replaces the original TZID in tz_entry::name with a combination of its TZNAMEs is still active, although it is no longer needed. It probably was added in the first place to preserve the two names so that they can be exported again. -- 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
