Timezone mapping is behaving little weird , For the same "Buenos Aire" meeting which I created logs and sent last week was mapped to "Africa/Harare", now same event getting mapped to "Standard Time/Daylight Savings Time 1".
I stepped through the code and in the "TIMEZONEtoInternal" function has GZOnes->matchTZ function to match the Timezone to loaded timezone definitions (tzcmp compares name,ident,bias,dst,std) and if that fails, replaces the TZID with TZNAME created from VTIMEZONE "STANDARD/TZNAME" which is "Standard Time" in this case and "DAYLIGHT/TZNAME" which is "Daylight Savings Time". In the matchTZ This time just the Timezone is wrong string but the event was displayed at the correct time in my evolution calendar. The only difference is now my evolution has just 2 events, earlier 15+. This probably not a bug if time is correct ,right? Thanks Raji -----Original Message----- From: Lukas Zeller [mailto:[email protected]] Sent: Wednesday, January 20, 2010 9:10 AM To: Ohly, Patrick Cc: Bommaraju, Rajyalakshmi; [email protected] Subject: Re: [os-libsynthesis] Outlook Recurring Event mapped to wrong Timezone after sync 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
