Re: [os-libsynthesis] Outlook Recurring Event mapped to wrong Timezone after sync
-Original Message- From: Ohly, Patrick Sent: Thursday, January 28, 2010 12:04 AM To: Bommaraju, Rajyalakshmi Cc: Lukas Zeller; os-libsynthesis@synthesis.ch Subject: RE: [os-libsynthesis] Outlook Recurring Event mapped to wrong Timezone after sync On Mi, 2010-01-27 at 18:18 +, Bommaraju, Rajyalakshmi wrote: > 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". Doing exactly the same kind of operation? It failed before and we haven't changed the code, so whatever caused the failure must still be around and could happen again. Raji--> I exactly did everything same as before. Do you have automated test coverage for the different time zones that you collected or do you run tests manually with that data? Raji -->I am running tests manually so far. > This probably not a bug if time is correct ,right? If a time zone with the right rules gets applied, the time will be right and we are treating the event correctly. But it needs to work reliably and we need automated tests for this. -- 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. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] Outlook Recurring Event mapped to wrong Timezone after sync
On Do, 2010-01-28 at 09:39 +, Lukas Zeller wrote: > We found that a definition for ART/ARST was missing in the built-in > time zones table of libsynthesis itself (a patch is on the way). > However in the SyncEvolution context, this list is not used but > superseded by the list imported from libical, as far as I know > (Patrick, correct me if I'm wrong). The internal list is extended, not superseded. I think the additional definitions are searched first. > So to find the reason for false matches (like the Africa/Harare case) > and the missing match for ART/ARST that imported data is the key. Right. -- 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. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] Outlook Recurring Event mapped to wrong Timezone after sync
Hi Raji, On Jan 27, 2010, at 19:18 , Bommaraju, Rajyalakshmi wrote: > 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". This is definitely better. "Africa/Harare" was a completely false match (for whatever reason). "Standard Time/Daylight Savings Time" means that there is no match for that VTIMEZONE, so libsynthesis creates a custom TZ definition from the VTIMEZONE. > 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". It would help if the VTIMEZONE TZNAME labels were more significant. Many VTIMEZONE generators put the time zone abbreviations like PST/PDT, CET/CEST or in your case ART/ARST, which results in a more meaningful time zone name. > In the matchTZ This time just the Timezone is wrong string but the event was > displayed at the correct time in my evolution calendar. Yes, the name is technically irrelevant when the actual time zone parameters in the VTIMEZONE are correct. The question is why the list of timezones read from libical does not have a definition for ART/ARST (or maybe it has one, but with different parameters from those in the VTIMEZONE). We found that a definition for ART/ARST was missing in the built-in time zones table of libsynthesis itself (a patch is on the way). However in the SyncEvolution context, this list is not used but superseded by the list imported from libical, as far as I know (Patrick, correct me if I'm wrong). So to find the reason for false matches (like the Africa/Harare case) and the missing match for ART/ARST that imported data is the key. Best Regards, Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] Outlook Recurring Event mapped to wrong Timezone after sync
On Mi, 2010-01-27 at 18:18 +, Bommaraju, Rajyalakshmi wrote: > 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". Doing exactly the same kind of operation? It failed before and we haven't changed the code, so whatever caused the failure must still be around and could happen again. Do you have automated test coverage for the different time zones that you collected or do you run tests manually with that data? > This probably not a bug if time is correct ,right? If a time zone with the right rules gets applied, the time will be right and we are treating the event correctly. But it needs to work reliably and we need automated tests for this. -- 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. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] Outlook Recurring Event mapped to wrong Timezone after sync
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:l...@synthesis.ch] Sent: Wednesday, January 20, 2010 9:10 AM To: Ohly, Patrick Cc: Bommaraju, Rajyalakshmi; os-libsynthesis@synthesis.ch 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 +, 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:19670101T00 > 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 (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
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 +, 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:19670101T00 > 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 (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] Outlook Recurring Event mapped to wrong Timezone after sync
On Mi, 2010-01-20 at 16:01 +, Lukas Zeller wrote: > Hello Raji, > > 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. > 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. Here it becomes relevant that SyncEvolution imports the Olson database via libical. That is where the "imported TZ: /softwarestudio.org/Tzfile/Africa/Harare" in the refresh-from-server comes from. 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 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:19670101T00 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. Raji, this will require some deep dive into the time zone handling and matching code that I mentioned earlier. You can speed up that process (no need to run a sync) by using "Buenos Aires.ics" with the "Standard Time/Daylight Savings Time" VTIMEZONE above as the content of the testcases/ical20.ics file when running "env CLIENT_TEST_SERVER=scheduleworld client-test Client::Sync::ical20::testConversion". I've attached that modified example. However, when I run that, I get yet some different results (times converted to localtime, no TZID). Strange. -- 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. BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 11.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST 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 BEGIN:VEVENT ATTENDEE;cn=rbommar...@yahoo.com;ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:rbommar...@yahoo.com ORGANIZER:MAILTO:rajyalakshmi.bommar...@intel.com DTSTART;TZID="Buenos Aires":20100117T183000 DTEND;TZID="Buenos Aires":20100117T19 RRULE:FREQ=WEEKLY;COUNT=2;INTERVAL=1;BYDAY=SU;WKST=SU TRANSP:OPAQUE SEQUENCE:0 UID:04008200E00074C5B7101A82E008F05FC51BC993CA01100 035CD89973931EA4E932578FA7DADA18C DTSTAMP:20100112T225210Z SUMMARY:Buenos Aires PRIORITY:5 X-MICROSOFT-CDO-IMPORTANCE:1 CLASS:PUBLIC BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] Outlook Recurring Event mapped to wrong Timezone after sync
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:20070225T00 RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU TZOFFSETFROM:-0200 TZOFFSETTO:-0300 END:STANDARD BEGIN:DAYLIGHT DTSTART:20071104T00 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: os-libsynthesis@synthesis.ch > Subject: Re: [os-libsynthesis] Outlook Recurring Event mapped to wrong > Timezone after sync > > On Mo, 2010-01-18 at 23:55 +, 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 mor
Re: [os-libsynthesis] Outlook Recurring Event mapped to wrong Timezone after sync
On Mo, 2010-01-18 at 23:55 +, 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. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
[os-libsynthesis] Outlook Recurring Event mapped to wrong Timezone after sync
Hi, 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. 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. Thanks, Raji Bommaraju BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 11.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Rio Branco BEGIN:STANDARD DTSTART:16010101T00 TZOFFSETFROM:-0500 TZOFFSETTO:-0500 TZNAME:Standard Time END:STANDARD END:VTIMEZONE BEGIN:VEVENT ATTENDEE;cn=rbommar...@yahoo.com;ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:rbommar...@yahoo.com ORGANIZER:MAILTO:rajyalakshmi.bommar...@intel.com DTSTART;TZID="Rio Branco":20100117T11 DTEND;TZID="Rio Branco":20100117T113000 RRULE:FREQ=WEEKLY;COUNT=1;INTERVAL=1;BYDAY=SU;WKST=SU TRANSP:OPAQUE SEQUENCE:0 UID:04008200E00074C5B7101A82E00800D2E7C79193CA01100 021167748FE87134BBA97F61F34D092CB DTSTAMP:20100112T191606Z SUMMARY:Bogota\, Lima\, Quito PRIORITY:5 X-MICROSOFT-CDO-IMPORTANCE:1 CLASS:PUBLIC BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
