@rfc2822
- 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:
Hi,
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é” jan.mate@inf-it.com
Betreff: Re: Problem with an appointment after sync with android clients
Hi Klaus,
according to RFC - https://tools.ietf.org/html/rfc5545 InfCloud behaviour is correct:
3.8.4.4. 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.
Cheers,
JM
