On Mi, 2010-01-20 at 16:01 +0000, 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: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. 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":20100117T190000 RRULE:FREQ=WEEKLY;COUNT=2;INTERVAL=1;BYDAY=SU;WKST=SU TRANSP:OPAQUE SEQUENCE:0 UID:040000008200E00074C5B7101A82E00800000000F05FC51BC993CA010000000000000000100 0000035CD89973931EA4E932578FA7DADA18C 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
