Tickets :: Comment on [#9726] Issues when synchronizing repeated events spanning DST change date

* Your Email Address
* Spam protection	Enter the letters below: . .. ,.__. __ . . \| \| \./ [__]/ `\|__\| \|/\\| \| \| \|\__.\| \|
Comment	> Hi, > > Here are some answers from Beat. They refer to the following message: > > BEGIN:VCALENDAR > VERSION:2.0 > X-WR-CALNAME:gerti's Calendar > PRODID:-//The Horde Project//Horde_iCalendar > Library\, Horde 3.3.8//EN > METHOD:PUBLISH > BEGIN:VEVENT > DTSTART:20110301T010000Z > DTEND:20110301T020000Z > DTSTAMP:20110327T142133Z > CREATED:20110327T142029Z > LAST-MODIFIED:20110327T142029Z > SUMMARY:Repeating One > ORGANIZER;CN=gerti:mailto:gerti > CLASS:PUBLIC > STATUS:CONFIRMED > TRANSP:OPAQUE > RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO;UNTIL=20110505T035959Z > EXDATE:20110328T000000Z > EXDATE:20110328T000000Z > END:VEVENT > END:VCALENDAR > >>> 1) The Horde server is sending VCALENDAR 2.0 format, though it does >>> not offer this format. The Synthesis client is accepting this >>> (because it's clear what the server is intending to do), but it's not >>> really according the SyncML standard. The Horde server should offer >>> VCALENDAR 2.0. >> >> What makes them do those claims? They are wrong. > > I'm correcting this. The Horde server is not returning an error > however when using "events" instead of "calendar" as server path > name. When using "calendar", the format (VCALENDAR 2.0) is correctly > recognized and available. > However the contents of the devInf are very poor (no available field > info and so on). > > >>> 3) The event is on Tuesday according to the given information, not on >>> Monday (as written in the RRULE) >>> It would be Monday in the local time zone, but no such information is sent. >> >> Sorry, I don't understand what you mean. > > DTSTART is 1-Mar-2011, which was a TUESDAY, not a MONDAY as written > in the RRULE > This might be side effect of 2) as there is no TZ info (see red > DTSTART/RRULE) > >>> 4) The Horde server is not sending a UID, that's why the Synthesis >>> client will add one and send it >>> back with the next sync. That's why the client sends back even >>> without any changes. >> >> UIDs are not supposed to be part of the iCalendar data. UIDs are >> exchanged in the SyncML protocol level. > > UIDs are definitively part of iCalendar 2.0, as only with them > RECURRENCE-ID can be implemented > This has nothing to do with SyncML protocol level. We consider a > workaround however for one of the next releases for events without > UID, to avoid sending it back at the next sync. > >>> 5) For sending back the Horde server does not allow UTC (and only >>> VCALENDAR 1.0), that's why the Synthesis is sending back the events >>> in floating format as VCALENDAR 1.0 which has several limitations for >>> EXDATES. >> >> No idea how you come to that conclusion. Horde accepts 1.0 and 2.0 >> data and of course UTC dates too. > > (Resolved when using "calendar" instead of "events") > > >>> 6) The Horde server is sending two times the same EXDATE which is not >>> correct. >>> This has no negative effect on client's side, but it's not ok that way. > > The 2 EXDATES (in red) are completely wrong, they are 2 times the > same and not an exception of > something defined in the RRULE. They do not hamper the Synthesis > client however. > > >> How exactly does this event look like in the database? > > Please tell me how to retrieve the information that you want. Is > there a specific SQL query you'd like me to execute? >
Attachment
Watch this ticket

Saved Queries