2 Apr
2014
2 Apr
'14
6:39 a.m.
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
2 Apr
2 Apr
7:33 a.m.
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(a)dmfs.org
twitter: twitter.com/dmfs_org
VAT Reg. No.: DE269072391
11:28 a.m.
Marten Gajda <marten(a)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
11:45 a.m.
Am 02.04.2014 13:28, schrieb Johan Vromans:
Marten Gajda <marten(a)dmfs.org> writes:
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.
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
--
Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany
tel: +49 177 4427167
email: marten(a)dmfs.org
twitter: twitter.com/dmfs_org
VAT Reg. No.: DE269072391
1:10 p.m.
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(a)squirrel.nl> wrote:
Marten Gajda <marten(a)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
10:15 p.m.
Ján Máté <jan.mate(a)inf-it.com> writes:
it was a bug, here is the fix (for 0.10.0.4):
http://www.inf-it.com/fixes/cdz_r_fix.diff
The duplicate entry is gone now. Good job!
-- Johan
3018
days inactive
3018
days old
5 comments
3 participants
participants (3)
-
Johan Vromans -
Ján Máté -
Marten Gajda