The Nextcloud update works quite well here (normal installation without snap). I don’t know whether Baikal is still supported; it was very simple to set up if I remember correctly. Or Radicale… or another one from davx5.com/tested-with/ 🙂
RECURRENCE-ID and DTSTART should have same time zone
- DAVdroid synchronizes this event:
V/davdroid(32418): BEGIN:VEVENT V/davdroid(32418): DTSTAMP:20161019T112935Z V/davdroid(32418): UID:1hfhkjybp8u V/davdroid(32418): SEQUENCE:1 V/davdroid(32418): DTSTART;TZID=Europe/Berlin:20161019T091500 V/davdroid(32418): DURATION:PT1H V/davdroid(32418): RRULE:FREQ=DAILY;COUNT=3 V/davdroid(32418): SUMMARY:Recur1 V/davdroid(32418): STATUS:CONFIRMED V/davdroid(32418): CLASS:PUBLIC V/davdroid(32418): CREATED:20161019T131131 V/davdroid(32418): END:VEVENT V/davdroid(32418): BEGIN:VEVENT V/davdroid(32418): DTSTAMP:20161019T112935Z V/davdroid(32418): UID:1hfhkjybp8u V/davdroid(32418): RECURRENCE-ID:20161020T071500Z V/davdroid(32418): SEQUENCE:1 V/davdroid(32418): DTSTART;TZID=Europe/Berlin:20161020T091500 V/davdroid(32418): DTEND;TZID=Europe/Berlin:20161020T101500 V/davdroid(32418): SUMMARY:Recur1 V/davdroid(32418): STATUS:CANCELLED V/davdroid(32418): END:VEVENT
That’s exactly what’s DAVdroid has queried from the database (using the calendar provider): a recurring event, where the instance on
**RECURRENCE-ID:20161020T071500Z**is marked as STATUS:CANCELLED.
I don’t see any room for interpretation here or where you see a problem. Maybe I have overseen something, but in this case, I would need a specific report on what’s wrong.
Sorry for picking up the old thread, but it fit pretty good to my problem.
Who is writing the RECURRENCE-ID in this case?
Because Recurrence-ID is given in utc and DTEND/DTSTART in lokal Time, whats produces duplicates and is standard.
Below I paste the email communication between me and the infcloud developper:
My question was:
On 19 Jan 2019, at 19:00, Klaus wrote:
Thank you for developing a frontend for Baikal!
Infcloud runs on a Synology NAS with Baikal as a calendar server for appointments, addresses and tasks.
Synchronization with Android clients make problems with recurring appointments, if they are edited and synchronized with Android calendar apps.
If a single appointment is deleted from a recurring appointment, it will be correctly removed from the infcloud webpanel view.
If a single appointment from a recurring appointment is only edited (start-/endtime edited), this recurrence will appear twice in infcloud. Once with the original time, the other time with the correct, new time.
I did a bit of analysis and found that the parameter RECURRENCE ID is the problem. It is always in GMT caused by the Android Calender / Sync programs. Without specifying the time zone (example: RECURRENCE ID: 20190115T110000Z).
Infcloud uses the specification in the local time:
RECURRENCE ID; TZID = Europe / Berlin: 20190115T120000
As an example, I have attached three ICS files, File 1 is the native appointment generated with infcloud. In File 2, the 15.01.2019 was changed by infcloud, in File 3, the 15.01.2019 was changed by Android. The result can be seen in the image files with the same name.
Thunderbird, Android Calendar and Outlook are clear with this information (method) and display the dates correctly.
Would it be possible to customize infcloud so that infcloud accepts dates in GMT times and displays no duplicates?
His answer was:
Gesendet: Samstag, 19. Januar 2019 um 20:46 Uhr
Von: “Ján Máté” email@example.com
Betreff: Re: Problem with an appointment after sync with android clients
according to RFC - https://tools.ietf.org/html/rfc5545 InfCloud behaviour is correct:
188.8.131.52. Recurrence ID Property Name: RECURRENCE-ID Purpose: This property is used in conjunction with the "UID" and "SEQUENCE" properties to identify a specific instance of a recurring "VEVENT", "VTODO", or "VJOURNAL" calendar component. The property value is the original value of the "DTSTART" property of the recurrence instance. Value Type: The default value type is DATE-TIME. The value type can be set to a DATE value type. This property MUST have the same value type as the "DTSTART" property contained within the recurring component. Furthermore, this property MUST be specified as a date with local time if and only if the "DTSTART" property contained within the recurring component is specified as a date with local time.
and the RFC https://tools.ietf.org/html/rfc2119 (which defines the “MUST” keyword) says:
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
The VEVENT instance from your “File 3” (Android) looks like:
BEGIN:VEVENT LAST-MODIFIED:20190119T112619Z DTSTAMP:20190119T112619Z UID:yr3smsul-rri3-y7ub-6iud-rsuqmv3f9gpw SUMMARY:Test Incloud STATUS:CONFIRMED RECURRENCE-ID:20190115T110000Z DTSTART;TZID=Europe/Berlin:20190115T120000 DTEND;TZID=Europe/Berlin:20190115T140000 LOCATION:Testhausen CLASS:PUBLIC TRANSP:OPAQUE SEQUENCE:1 END:VEVENT
=> the DTSTART is specified in local time, but the RECURRENCE-ID in GMT => exactly the opposite of what RFC says.
I have sent an APK to your email address. Can you confirm that this version works for you?
Thanks for the confirmation over email. This fix will be included in the next version of DAVx⁵.