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

* Your Email Address
* Spam protection	Enter the letters below: . ..__ .__ .__ .___ \|\ \|[__)[__)[ __[__ \| \\|[__)\| \[_./\|
Comment	>> 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. > > It should work fine with both "events" and "calendar" since they are aliases. > >> 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) > > Yes, could be side-effect. > >>>> 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. > > The problem with UIDs is that some clients do not generate valid > UIDs, i.e. they are not unique at all. To work around that, we always > ignore UIDs sent from clients, and don't sent them back to clients > either. > > But he is right, this will of course break attributes like > RECURRENCE-ID. There is no easy way around this though. >>>> 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. > > Like I said, I need the event details from the database to say > anything about that. EXDATEs are generated from recurrence exceptions > stored in the calendar. Whether they actually match any of the > recurrences is not validated and not necessary either. > >>> 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? > > Try something like: > SELECT * FROM kronolith_events WHERE event_title = "Repeating One"
Attachment
Watch this ticket

Saved Queries