Hi,
I use Business Calendar Pro on Android. I change one occurrence of a repeating appointment to a different time and now I have a duplicate ID on the DAViCal server:
BEGIN:VEVENT CREATED:20140106T230106Z SUMMARY:**** TRANSP:OPAQUE CLASS:PUBLIC DTSTART;TZID=Europe/Berlin:20140226T093000 LOCATION:**** STATUS:CONFIRMED EXDATE:20140312T083000Z EXDATE:20140326T083000Z EXDATE:20140319T083000Z RRULE:FREQ=WEEKLY;WKST=MO;UNTIL=20141224T083000Z DURATION:PT2H30M LAST-MODIFIED:20140320T214312Z DTSTAMP:20140320T214312Z SEQUENCE:3 UID:bkdiwaiy-cmbs-xjpc-pe24-gd16ybt4mfeu END:VEVENT
BEGIN:VEVENT DTSTART;TZID=Europe/Berlin:20140402T103000 SUMMARY:**** LOCATION:**** CLASS:PUBLIC TRANSP:OPAQUE STATUS:CONFIRMED DTEND;TZID=Europe/Berlin:20140402T123000 LAST-MODIFIED:20140401T221005Z DTSTAMP:20140401T221005Z SEQUENCE:1 RECURRENCE-ID:20140402T073000Z UID:bkdiwaiy-cmbs-xjpc-pe24-gd16ybt4mfeu END:VEVENT
This was the original event:
BEGIN:VEVENT CREATED:20140106T230106Z SUMMARY:**** TRANSP:OPAQUE CLASS:PUBLIC DTSTART;TZID=Europe/Berlin:20140226T093000 LOCATION:**** STATUS:CONFIRMED EXDATE:20140312T083000Z EXDATE:20140326T083000Z EXDATE:20140319T083000Z RRULE:FREQ=WEEKLY;WKST=MO;UNTIL=20141224T083000Z DURATION:PT2H30M LAST-MODIFIED:20140320T214312Z DTSTAMP:20140320T214312Z SEQUENCE:3 UID:bkdiwaiy-cmbs-xjpc-pe24-gd16ybt4mfeu END:VEVENT
Can I blame this to Business Calendar Pro?
-- Johan
I presume both VEVENTS are enclosed in the same VCALENDAR object, are they? That's correct behavior. In this case both events *must* have the same UID because it's essentially the same event (just with an exception). The exception instance has a RECURRENCE-ID to specify the exact instance of the event that is replaced by the exception.
cheers
Marten
Am 02.04.2014 08:39, schrieb Johan Vromans:
Hi,
I use Business Calendar Pro on Android. I change one occurrence of a repeating appointment to a different time and now I have a duplicate ID on the DAViCal server:
BEGIN:VEVENT CREATED:20140106T230106Z SUMMARY:**** TRANSP:OPAQUE CLASS:PUBLIC DTSTART;TZID=Europe/Berlin:20140226T093000 LOCATION:**** STATUS:CONFIRMED EXDATE:20140312T083000Z EXDATE:20140326T083000Z EXDATE:20140319T083000Z RRULE:FREQ=WEEKLY;WKST=MO;UNTIL=20141224T083000Z DURATION:PT2H30M LAST-MODIFIED:20140320T214312Z DTSTAMP:20140320T214312Z SEQUENCE:3 UID:bkdiwaiy-cmbs-xjpc-pe24-gd16ybt4mfeu END:VEVENT
BEGIN:VEVENT DTSTART;TZID=Europe/Berlin:20140402T103000 SUMMARY:**** LOCATION:**** CLASS:PUBLIC TRANSP:OPAQUE STATUS:CONFIRMED DTEND;TZID=Europe/Berlin:20140402T123000 LAST-MODIFIED:20140401T221005Z DTSTAMP:20140401T221005Z SEQUENCE:1 RECURRENCE-ID:20140402T073000Z UID:bkdiwaiy-cmbs-xjpc-pe24-gd16ybt4mfeu END:VEVENT
This was the original event:
BEGIN:VEVENT CREATED:20140106T230106Z SUMMARY:**** TRANSP:OPAQUE CLASS:PUBLIC DTSTART;TZID=Europe/Berlin:20140226T093000 LOCATION:**** STATUS:CONFIRMED EXDATE:20140312T083000Z EXDATE:20140326T083000Z EXDATE:20140319T083000Z RRULE:FREQ=WEEKLY;WKST=MO;UNTIL=20141224T083000Z DURATION:PT2H30M LAST-MODIFIED:20140320T214312Z DTSTAMP:20140320T214312Z SEQUENCE:3 UID:bkdiwaiy-cmbs-xjpc-pe24-gd16ybt4mfeu END:VEVENT
Can I blame this to Business Calendar Pro?
-- Johan
Marten Gajda marten@dmfs.org writes:
I presume both VEVENTS are enclosed in the same VCALENDAR object, are they?
Yes, they are.
That's correct behavior. In this case both events *must* have the same UID because it's essentially the same event (just with an exception). The exception instance has a RECURRENCE-ID to specify the exact instance of the event that is replaced by the exception.
Ok, good to hear...
Then the next question is: why does CalDAVzap show *both* occurrences (the original one @09:30 and the modified one @10:30)?
-- Johan
Am 02.04.2014 13:28, schrieb Johan Vromans:
Marten Gajda marten@dmfs.org writes:
I presume both VEVENTS are enclosed in the same VCALENDAR object, are they?
Yes, they are.
That's correct behavior. In this case both events *must* have the same UID because it's essentially the same event (just with an exception). The exception instance has a RECURRENCE-ID to specify the exact instance of the event that is replaced by the exception.
Ok, good to hear...
Then the next question is: why does CalDAVzap show *both* occurrences (the original one @09:30 and the modified one @10:30)?
Maybe because DTSTART and RECURRENCE-ID have different time zones (which is perfectly valid)? Please try to replace
RECURRENCE-ID:20140402T073000Z
by
RECURRENCE-ID;TZID=Europe/Berlin:20140402T093000
and check if that issue still exists.
-- Johan
Hi Johan,
it was a bug, here is the fix (for 0.10.0.4):
http://www.inf-it.com/fixes/cdz_r_fix.diff
steps to apply it: - copy the file into the caldavzap directory - use: patch -p1 < cdz_r_fix.diff - update cache: ./cache_update.sh
JM
p.s.: please report if it fixes your problem
On 02 Apr 2014, at 13:28, Johan Vromans jvromans@squirrel.nl wrote:
Marten Gajda marten@dmfs.org writes:
I presume both VEVENTS are enclosed in the same VCALENDAR object, are they?
Yes, they are.
That's correct behavior. In this case both events *must* have the same UID because it's essentially the same event (just with an exception). The exception instance has a RECURRENCE-ID to specify the exact instance of the event that is replaced by the exception.
Ok, good to hear...
Then the next question is: why does CalDAVzap show *both* occurrences (the original one @09:30 and the modified one @10:30)?
-- Johan
Ján Máté jan.mate@inf-it.com writes:
it was a bug, here is the fix (for 0.10.0.4):
The duplicate entry is gone now. Good job!
-- Johan
-
Johan Vromans -
Ján Máté -
Marten Gajda