Hi Patrick, On Jan 20, 2010, at 17:35 , Patrick Ohly wrote:
> On Mi, 2010-01-20 at 16:01 +0000, Lukas Zeller wrote: >> I don't know enough of the SyncEvolution part to see what transformations >> the ics undergoes before it is passed to libsynthesis. > > None. I think what Raji meant with "by the script of syncevolution" is > the process in libsynthesis that you described. Ok. > The reason why the matching yields different results is probably the > DTSTART rule of the VTIMEZONE. In the origin even from Outlook, the > definition is: > > BEGIN:VTIMEZONE > TZID:Buenos Aires > BEGIN:STANDARD > ====> DTSTART:20090314T235900 > RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SA;BYMONTH=3 > TZOFFSETFROM:-0200 > TZOFFSETTO:-0300 > TZNAME:Standard Time > END:STANDARD > BEGIN:DAYLIGHT > ====> DTSTART:20091017T235900 > RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=3SA;BYMONTH=10 > TZOFFSETFROM:-0300 > TZOFFSETTO:-0200 > TZNAME:Daylight Savings Time > END:DAYLIGHT > END:VTIMEZONE > > After importing this timezone, it gets exported differently while > sending to ScheduleWorld: > > BEGIN:VTIMEZONE > TZID:Standard Time/Daylight Savings Time > BEGIN:STANDARD > ====> DTSTART:19670311T235900 > RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=2SA > TZOFFSETFROM:-0200 > TZOFFSETTO:-0300 > TZNAME:Standard Time > END:STANDARD > BEGIN:DAYLIGHT > ====> DTSTART:19871017T235900 > RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=3SA > TZOFFSETFROM:-0300 > TZOFFSETTO:-0200 > TZNAME:Daylight Savings Time > END:DAYLIGHT > END:VTIMEZONE I see - but for dates in 2009 an the future, IMHO both are equivalent. > Then when that comes back from ScheduleWorld, it is then matched against > the libical timezone, yielding the following when storing it in > Evolution: > > BEGIN:VTIMEZONE > TZID:/softwarestudio.org/Tzfile/Africa/Harare > BEGIN:STANDARD > DTSTART:19670101T000000 > TZOFFSETFROM:+0200 > TZOFFSETTO:+0200 > END:STANDARD > END:VTIMEZONE > > It is strange that this match is made at all, given that Harare has > hardly anything in common with Buenos Aires. Yes, that's the really strange part. But it must be related to the zone definitions imported from libical. When using the built-in table, the same vCalendar that leads to Africa/Harare in your case correctly creates a "custom time zone", because no matching definition exists in the internal table. So it might make sense to check what exactly are the parameters of the libical imported Africa/Harare zone, and why these could possibly match with a zone as different as Buenos Aires. Best Regards, Lukas Zeller ([email protected]) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts [email protected], http://www.synthesis.ch _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
