Hello Raji, I don't know enough of the SyncEvolution part to see what transformations the ics undergoes before it is passed to libsynthesis.
However I see that when I feed your "Buenos Aires.ics" into libsynthesis directly, it is not recognized as one of the know time zone but added as a "custom" zone to the libsynthesis time zone list. Unfortunatley, as the TZNAME properties are just called "Standard Time" and "Daylight Savings Time", and libsynthesis constructs the internal zone name from these properties, it ends up as a time zone named "Standard Time/Daylight Savings Time", which is a pretty meaningless name. The main question for me is why the zones get misinterpreted (in your syncevolution-log-2-buenos-aire-from-server.html I see that the zone is detected as "Africa/Harare") or considered custom time zones, because it is known as "East_South_America" in libsynthesis' internal list of built-in zones. Looking at libsynthesis' zone definition: BEGIN:VTIMEZONE TZID:East_South_America BEGIN:STANDARD DTSTART:20070225T000000 RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU TZOFFSETFROM:-0200 TZOFFSETTO:-0300 END:STANDARD BEGIN:DAYLIGHT DTSTART:20071104T000000 RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=1SU TZOFFSETFROM:-0300 TZOFFSETTO:-0200 END:DAYLIGHT END:VTIMEZONE and comparing it with the VTIMEZONE in your .ics: 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 shows that the daylight savings switch rule is quite different. Our definition says last sunday in February, yours says seconds saturday in march. I seems to me that "East_South_America" is not the correct time zone for Buenos Aires for some reason, or it has wrong parameters in our list. This explains why the zone is not dectect as one of the internal zones, however it does not answer why there should be problems in the sync, and how it mutates into "Africa/Harare" later on. libsynthesis treats the zone as a custom zone (with a meaningless name) but with correct parameters according to the VTIMEZONE in your .ics. so processing should be fine. Best Regards, Lukas Zeller On Jan 20, 2010, at 2:09 , Bommaraju, Rajyalakshmi wrote: > Patrick, > Attached better example event . Also attached verbose log files generated > during the sync.For this new example it looked like "Buenos Aire" timezone is > converted to "standard day light time" by the script of syncevolution before > handing it off to libsynthesis. Please correct me if I am wrong, Schedule > world calendar shows the timezone sent from the client and hands over the > same thing back to client during sync with "refresh-from-server" option. > > syncevolution-log-2-buenos-aire-from-client.html is captured with > "refresh-from-client" option. > syncevolution-log-2-buenos-aire-from-server.html is captured with > "refresh-from-server" option. > > Thanks > Raji > ________________________________________ > From: Ohly, Patrick > Sent: Tuesday, January 19, 2010 11:25 AM > To: Bommaraju, Rajyalakshmi > Cc: [email protected] > Subject: Re: [os-libsynthesis] Outlook Recurring Event mapped to wrong > Timezone after sync > > On Mo, 2010-01-18 at 23:55 +0000, Bommaraju, Rajyalakshmi wrote: >> I am trying to sync evolution calendar with calendar on Scheduleworld >> using SyncEvolution tool. My evolution calendar has some imported >> outlook recurring events, some of the events gave problem , it was >> created with “Bogota, Lima ” (UTC-5:00)in outlook, when I imported it >> and synced it was mapped to America/Los Angeles (UTC-8:00) and >> meeting time was wrong. > > Please have a close look at the conversion that take place and try to > figure out where the time zone goes wrong: > - inside libsynthesis when sending to ScheduleWorld > - on ScheduleWorld > - inside libsynthesis when receiving from ScheduleWorld > > You can find out about this by running at loglevel 4 and looking into > the item conversions in the syncevolution-log.html. > >> How timezone mapping is done in libsynthesis, where and what is the >> best way to fix this problem. I attached the example event file. >> Appreciate your help. > > That depends a bit on what really goes wrong. > > My understanding of the issue when I looked at it a while ago was that > ScheduleWorld works better with time zones which have an Olsen TZID. If > we can detect the more difficult Microsoft time zone definitions and > replace them with more standard ones, sync might work better overall. > > Now in your example, this is exactly what I see happening: > * libsynthesis gets TZID=Rio Branco and maps it to TZ: SA_Pacific, > which is encoded as TZID=America/Bogota > * ScheduleWorld sends the item back with that time zone > > I was testing with the current "master" branches of SyncEvolution and > libsynthesis. As of a few hours ago, they contain your patches for the > "can't encode item" problem in Evolution. > > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > > <syncevolution-log-2-buenos-aire-from-client.html><syncevolution-log-2-buenos-aire-from-server.html><Buenos > Aires.ics>_______________________________________________ > os-libsynthesis mailing list > [email protected] > http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis 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
