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

Search Results: 35 of 248 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: . .. ,.__.. ..__ \| \| \./ \| \|\ /[ __ \|__\| \| \|__\ \/ [_./
Comment	>> 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. > >> 2) The Horde server is sending it as UTC without any timezone information. >> That works for single events, but not for repeating events over the >> DST change date. >> The Android client stores it locally in UTC timezone (without any DST rule). >> The Horde server should send the VCALENDAR information for the given >> timezone. > > Duplicate of ticket #7156. > >> 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. > >> 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. > >> 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. > >> 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. > > How exactly does this event look like in the database?
Attachment
Watch this ticket

Saved Queries