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 Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391
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
-- Marten Gajda Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391
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
participants (3)
-
Johan Vromans -
Ján Máté -
Marten Gajda