tis 2004-01-27 klockan 10.23 skrev Olof Gunnarsson: > Hi all. > > P800 <> Evolution. Multisync CVS040105. Using cradle. Evolution 1.4.5. > > I have problems syncing either way. > > * P800 > Evolution: > All events show up one hour later than expected (1600 becomes 1700). > Timezones are the same in Evolution and the p800. > > * Evolution > P800: > All entries are duplicated in the P800 and with the correct time. If I > sync a third time, there are 3 entries in the P800. > > This is reproducable every time. > > Attached is the output from multisync. > > I would really like this to work. Anyone got any ideas?
I have the same problem and have done some logging etc. Sorry for my english, but it's NOT my native language. I have done some analysez of the problem with syncronisation of calendar entries between my P900 and evolution with multisync 0.81 (the debian unstable packages). The international settings of my P900 is Stockholm/Sweden on both entries. My evolution have Europe/Stockholm as Timezone, and my computer is in CET. Creating an entry on my P900 at 1400, and running ethereal to se what is flowing over the ppp link. <Data><![CDATA[BEGIN:VCALENDAR VERSION:1.0 BEGIN:VEVENT UID:1608 SUMMARY:14 DTSTART:20040303T140000Z DTEND:20040303T150000Z X-EPOCAGENDAENTRYTYPE:APPOINTMENT CLASS:PUBLIC DCREATED:20040303T000000Z LAST-MODIFIED:20040303T083600Z PRIORITY:0 STATUS:NEEDS ACTION END:VEVENT END:VCALENDAR ]]></Data> The P900 should be in timezone Sweden, but it's encoding the DTSTART as it's in UTC, this is probably a bugg in the Calendar application on the P900. If I send the same information calendar information as email, the DTSTART/DTEND entries are encoded in localzone, ie without Z. According to SE support the SyncML timezone information is depending on the country settings you choose when you start P900 the first time or after a master reset (or software upgrade), and not the settings from Control Panel->International, but after a master reset I do have the same problem. Multisync try to convert the UTC time to localtime as showed in the following debug output. SyncML: Using SyncML 1.0 SyncML: The maximum message size is 200000 bytes. SyncML: Action: 1 0 0 0 SyncML: *** Got change results! *** Got 1 changes. Change type: 2, object type: 1 Comp: BEGIN:VCALENDAR VERSION:2.0 BEGIN:VEVENT UID:1608 SUMMARY:14 DTSTART:20040303T150000 DTEND:20040303T160000 X-EPOCAGENDAENTRYTYPE:APPOINTMENT CLASS:PUBLIC DCREATED:20040303T000000Z LAST-MODIFIED:20040303T083600Z PRIORITY:0 STATUS:NEEDS ACTION END:VEVENT END:VCALENDAR If we send stuff the other way (from Evo to P900) we get the following results: >From the debug output we first got the information from Evo, omp: BEGIN:VCALENDAR VERSION:2.0 BEGIN:VEVENT UID:[EMAIL PROTECTED] DTSTAMP:20040303T084956Z DTSTART;TZID=/softwarestudio.org/Olson_20011030_5/Europe/Stockholm: 20040303T160000 DTEND;TZID=/softwarestudio.org/Olson_20011030_5/Europe/Stockholm: 20040303T163000 TRANSP:OPAQUE SEQUENCE:2 SUMMARY:1600 from Evolution CLASS:PUBLIC LAST-MODIFIED:20040303T085007Z END:VEVENT END:VCALENDAR With a full Timezone information. In my mind the most correct implementation should convert the DTSTART/DTEND entries to UTC, but acording to Bo this is hard with the current evolution API. The debug output in the syncml plugin: VERSION:1.0 BEGIN:VEVENT UID:[EMAIL PROTECTED] DTSTAMP:20040303T084956Z DTSTART:20040303T160000 DTEND:20040303T163000 TRANSP:OPAQUE SEQUENCE:2 SUMMARY:1600 from Evolution CLASS:PUBLIC LAST-MODIFIED:20040303T085007Z END:VEVENT END:VCALENDAR ]] Now we have stripped the timezone information, and this is still correct to do, if booth side have the same local timezone and the timezone information was the local timezone. Ethereal output is the same. <Data><![CDATA[BEGIN:VCALENDAR VERSION:1.0 BEGIN:VEVENT UID:[EMAIL PROTECTED] DTSTAMP:20040303T084956Z DTSTART:20040303T160000 DTEND:20040303T163000 TRANSP:OPAQUE SEQUENCE:2 SUMMARY:1600 from Evolution CLASS:PUBLIC LAST-MODIFIED:20040303T085007Z END:VEVENT END:VCALENDAR ]]></Data> And because the local zone if the P900 is UTC, it's shown as at correct time. But the next time we syncronize, it's reported as UTC, and then multisync convert the information. Proposed solution: Add a setting for the syncml plugin to NOT convert the DTSTART/DTEND entries to localtime. This is an ugly solutions, but it should work. Sincerely Mikael ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Multisync-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/multisync-users
