Bug 169336 - Events excluded or deleted in a recurring event block still show in other clients subscribed to a calendar (see RFC 2445 re. EXDATE)
Summary: Events excluded or deleted in a recurring event block still show in other cli...
Status: RESOLVED FIXED
Alias: None
Product: korganizer
Classification: Applications
Component: general (show other bugs)
Version: 5.4.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Philipp Schmidt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-18 07:29 UTC by Rick Harris
Modified: 2021-03-24 23:32 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.17.0
Sentry Crash Report:


Attachments
patch for incidenceeditor (2.71 KB, patch)
2017-09-25 11:30 UTC, Jochen Trumpf
Details
patch for korganizer (1.21 KB, patch)
2017-09-25 11:30 UTC, Jochen Trumpf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rick Harris 2008-08-18 07:29:30 UTC
Version:            (using KDE 3.5.9)
Compiler:          gcc-4.1.2 
OS:                Linux
Installed from:    Gentoo Packages

Steps to reproduce:
1. Create a calendar in Korganizer with a recurring event.
2. Add some exclusion dates in the middle of the recurring event's start/end dates.
3. Fire up an RFC compliant iCalendar client such as 'Windows Calendar' or Mac's 'iCal' and subscribe to the newly created Korganizer calendar.
4. The recurring event that falls on the excluded dates is still shown in those clients even though they are not visible in Korganizer.

Expected behaviour:
Recurring events falling on excluded dates should not show up.

Notes:
Creating iCalendar.ics files from each of these three clients and comparing them shows that Korganizer does not respect the proper use of the EXDATE recurrence property as laid down in RFC 2445, Section 4.2.19.

Examples shown below are for a recurring event starting on 21/9/08, recurring every 8 days for 7 occurrences, with an exclusion date set on 7/10/08:
Windows Calendar.ics
DTSTART;TZID=Adelaide:20080921T060000
DTEND;TZID=Adelaide:20080921T180000
EXDATE;TZID=Adelaide:20081007T060000

iCal.ics
DTSTART;TZID=Australia/Adelaide:20080921T060000
EXDATE;TZID=Australia/Adelaide:20081007T060000
DTEND;TZID=Australia/Adelaide:20080921T180000

Korganizer.ics
EXDATE;VALUE=DATE:20081007
DTSTART:20080920T203000Z
DTEND:20080921T083000Z

Note that the 'VALUE=DATE' parameter is only valid for the DTSTART, DTEND and RDATE properties (not EXDATE), and that EXDATE is also missing the TZID parameter.

Thanks :)
Comment 1 Stas Verberkt 2009-01-16 12:48:57 UTC
According to RFC 2445 4.8.5.1
The value=date part is valid, but it seems other iCal software don't handle it well.

When you create an iCal file with this format Mozilla Sunbird, for example, still shows the exception.
But when you alter it to a date-time format (the default specified by the RFC). The exception is recognized.

Examples:
Doesn't work in other software:
EXDATE;VALUE=DATE:20090101
Does work in other software:
EXDATE:20090101T010000Z

Altough this seems to be a bug in other software it may be a good idea to use this default behaviour anyway.
Comment 2 Sergio Martins 2011-07-15 13:50:29 UTC
KOrganizer is respecting the RFC, please open a bug report in "other software"
Comment 3 Marten 2012-05-13 21:38:30 UTC
Please open this bug again! Who says this is RFC 2445 compliant? Have you ever thought about this issue?

Yes, VALUE=DATE is valid for EXDATE, but only for all-day events, not for DATE-TIME events.
I know that RFC 2445 is not clear about that, but it takes just a minute to understand that a VALUE=DATE EXDATE in combination to a VALUE=DATE-TIME DTSTART won't work.

Just consider a daily repeating event (e.g. a conference call) with
DTSTART;TZID=Europe/Berlin:20120105T030000
and
EXDATE;VALUE=DATE:20120110

What would happen if someone in New York get's this invitation? He would take his telephone on 2012-01-09 at 9:00 pm and dial the conference number but no one in Berlin would join in since it's already Jan 10th in Berlin. On the next day the guys in Berlin would join the conference call but the guy in New York would be absent.

Remember VALUE=DATE means the date is floating and always in local time!

This combination of DATE and DATE-TIME values is ambiguous. The specs say that the type of the DTSTART and the DTEND value must match. I guess it should be clear now that this is true for EXDATE as well, just like it is for RECURRENCEID and the original instance's DTSTART.

An EXDATE is pointless if it doesn't specify the exact instance that is excluded. You should think of an EXDATE as some kind of RECURRENCEID for events that don't take place.

That's the reason that no other client creates VALUE=DATE EXDATEs unless the event is an all-day event.
Comment 4 Rick Harris 2012-05-19 09:29:52 UTC
Does anyone use 3.5 anymore and is this still a problem with korganizer 4.8.x ?

4.8.x actually uses TZID now but still uses EXDATE;VALUE=DATE for time specified events, and I'm unable to test more thoroughly these days/years...

BTW marten, compliments on your android caldav work, I use this all the time.
Comment 5 Henning Becker 2012-05-19 09:43:01 UTC
(In reply to comment #4)
> Does anyone use 3.5 anymore and is this still a problem with korganizer
> 4.8.x ?
Hi Rick,
yes, it's still a problem in 4.8.3.
> 
> 4.8.x actually uses TZID now but still uses EXDATE;VALUE=DATE for time
> specified events, and I'm unable to test more thoroughly these days/years...
> 
> BTW marten, compliments on your android caldav work, I use this all the time.
Comment 6 Philipp Schmidt 2012-08-03 17:41:13 UTC
Still present with 4.9.0. Makes Syncing with mobile or other devices really tiresome. For every Exception I have to start Thunderbird with Lighning and add it there...
Comment 7 David Jarvie 2012-08-06 13:08:46 UTC
There is a case for using EXDATE with DATE values in the case of a sub-daily recurrence (i.e. hours/minutes). In this case, the exception would cancel multiple instances of the recurrence set which fall on the exception date. The TZID issue would still be relevant here, of course.

I can't find anything in RFC2445 which prohibits the use of TZID with DATE values. Section 4.8.5.1 appears to allow TZID with EXDATE;VALUE=DATE. Section 4.2.19 which defines TZID only mentions using TZID with DATE-TIME or TIME values, but doesn't prohibit its use with DATE values. So perhaps a solution would be to add TZID to EXDATE values, where applicable. I don't know how this would be handled by other calendaring software, though.
Comment 8 Philipp Schmidt 2012-08-06 15:51:08 UTC
(In reply to comment #7)
Valid, yes. Sensible, no. The Thing is that no program I know of actually implements sub-daily recurrences. And following the standard just for its own sake would be stupid in my opinion, especially as other, more widely used software does it differently, while still operating within the confines of the RFC.
KOrganizer does have the functionality to recognize DATE exceptions, my (work in progress) patch won't change that. It will just change the default way of saving exceptions so that the evermore important interoperability with mobile devices is restored.
Comment 9 Denis Kurz 2016-09-24 18:49:23 UTC
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of korganizer (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 10 Denis Kurz 2017-01-07 22:01:50 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.
Comment 11 Rick Harris 2017-01-14 04:22:10 UTC
Re-opened as this bug is still present in the latest 5.4.0 version (16.12).

This bug is extremely easy to reproduce, can we please only close bugs when they're fixed and not because the software gets version bumped - thanks :)
Comment 12 Jochen Trumpf 2017-09-24 10:00:19 UTC
I can confirm this issue is still present in version 17.08.1. Even if you were to take a literal interpretation of the RFC, the following is surely a bug: As pointed out in Comment #7 by David Jarvie, a DATE based exemption of a DATE-TIME recurrence would need to be interpreted as exempting all occurrences that intersect that (floating) DATE. However, if you select only one specific occurrence in the korganizer GUI, it writes a DATE based exemption to the ical file which in that case would also exempt the other intersecting occurrences that were not selected.

The only way this can be made consistent is to write a TZID plus DATE-TIME based exemption if the user selects and deletes a specific occurrence of a recurring event with a TZID and DATE-TIME based DTSTART, which is exactly what Windows, Apple, Thunderbird, etc. all do ...
Comment 13 Jochen Trumpf 2017-09-25 11:30:21 UTC
Created attachment 108008 [details]
patch for incidenceeditor
Comment 14 Jochen Trumpf 2017-09-25 11:30:52 UTC
Created attachment 108009 [details]
patch for korganizer
Comment 15 Jochen Trumpf 2017-09-25 11:42:03 UTC
The above two patches against 17.08.1 fix this issue for me. My calendar setup is rather basic with everything in a single timezone and I have not tested if the patches would work with multiple timezones. But at least they give a pointer to where to start.

The approach taken in the patches is to make this change seamless for the user. Everything looks and behaves the same from their perspective but what gets written to the iCal resource changes. 

The current korganizer GUI is limited compared to the full KCalCore API for recurrence. I have tried to map the existing limitations in the GUI best possible to the KCalCore API (except for the currently naive handling of timezones). 

This would break if the korganizer GUI would ever allow sub-daily recurrence. But for now we can write DATE entries for all day recurrences and DATE-TIME entries otherwise. I am unsure how to properly merge the exception dates from the GUI into the exDateTimes in the case of different timezones. There is probably an API for that in KCalCore but I did not check.

The patches are not doing anything fancy so properly porting to Qt5 should be straightforward.
Comment 16 Jochen Trumpf 2017-09-25 11:44:06 UTC
Oh, and I forgot to say, obviously one needs to fix existing iCal resources by hand or discard them and start from scratch.
Comment 17 Bug Janitor Service 2021-03-24 15:55:39 UTC
A possibly relevant merge request was started @ https://invent.kde.org/pim/incidenceeditor/-/merge_requests/15
Comment 18 Bug Janitor Service 2021-03-24 15:57:34 UTC
A possibly relevant merge request was started @ https://invent.kde.org/pim/korganizer/-/merge_requests/20
Comment 19 gjditchfield 2021-03-24 22:28:55 UTC
Git commit bccc8998ce2cc867e6508bf4a6ddd8630c32e500 by Glen Ditchfield.
Committed on 24/03/2021 at 15:38.
Pushed by gditchfield into branch 'release/21.04'.

Add time and time zone to EXDATEs of DATE-TIME instances

KOrganizer creates DATE values for exceptions to recurring
instances, even if the incidence is not "all day" (i.e. DTSTART is a
DATE-TIME value).  EXDATE identifies a specific instance and arguably
should follow the same rules as RECURRENCE-ID.  RFC 5545 does not say
so, but [erratum 6316](https://www.rfc-editor.org/errata/eid6316) does.
In practice, other important systems reject EXDATEs that do not match
DTSTART.

Original patch written by Jochen.Trumpf@anu.edu.au.
Related: bug 434559
FIXED-IN: 5.17.0

M  +9    -3    src/calendarview.cpp

https://invent.kde.org/pim/korganizer/commit/bccc8998ce2cc867e6508bf4a6ddd8630c32e500
Comment 20 gjditchfield 2021-03-24 22:29:25 UTC
Git commit 261ac6e7e2b0d7cd19f0624c1555648f65db2b92 by Glen Ditchfield.
Committed on 24/03/2021 at 14:58.
Pushed by gditchfield into branch 'release/21.04'.

Add time and time zone to EXDATEs of DATE-TIME instances

The incidence editor creates DATE values for exceptions to recurring
instances, even if the incidence is not "all day" (i.e. DTSTART is a
DATE-TIME value).  EXDATE identifies a specific instance and arguably
should follow the same rules as RECURRENCE-ID.  RFC 5545 does not say
so, but [erratum 6316](https://www.rfc-editor.org/errata/eid6316) does.
In practice, other important systems reject EXDATEs that do not match
DTSTART.

Original patch written by Jochen.Trumpf@anu.edu.au.
Related: bug 434559
FIXED-IN: 5.17.0

M  +58   -9    src/incidencerecurrence.cpp
M  +1    -0    src/incidencerecurrence.h

https://invent.kde.org/pim/incidenceeditor/commit/261ac6e7e2b0d7cd19f0624c1555648f65db2b92
Comment 21 gjditchfield 2021-03-24 22:37:53 UTC
*** Bug 434599 has been marked as a duplicate of this bug. ***
Comment 22 gjditchfield 2021-03-24 23:25:08 UTC
Git commit 77fd1246f391e26a3e767d575f7db302da2c6c43 by Glen Ditchfield.
Committed on 24/03/2021 at 23:14.
Pushed by gditchfield into branch 'master'.

Add time and time zone to EXDATEs of DATE-TIME instances

The incidence editor creates DATE values for exceptions to recurring
instances, even if the incidence is not "all day" (i.e. DTSTART is a
DATE-TIME value).  EXDATE identifies a specific instance and arguably
should follow the same rules as RECURRENCE-ID.  RFC 5545 does not say
so, but [erratum 6316](https://www.rfc-editor.org/errata/eid6316) does.
In practice, other important systems reject EXDATEs that do not match
DTSTART.

Original patch written by Jochen.Trumpf@anu.edu.au.
Related: bug 434599
FIXED-IN: 5.17.0

M  +58   -9    src/incidencerecurrence.cpp
M  +1    -0    src/incidencerecurrence.h

https://invent.kde.org/pim/incidenceeditor/commit/77fd1246f391e26a3e767d575f7db302da2c6c43
Comment 23 gjditchfield 2021-03-24 23:32:04 UTC
Git commit 551d46c276bddb735386787d0141c83888695c44 by Glen Ditchfield.
Committed on 24/03/2021 at 23:29.
Pushed by gditchfield into branch 'release/21.04'.

Add time and time zone to EXDATEs of DATE-TIME instances

KOrganizer creates DATE values for exceptions to recurring
instances, even if the incidence is not "all day" (i.e. DTSTART is a
DATE-TIME value).  EXDATE identifies a specific instance and arguably
should follow the same rules as RECURRENCE-ID.  RFC 5545 does not say
so, but [erratum 6316](https://www.rfc-editor.org/errata/eid6316) does.
In practice, other important systems reject EXDATEs that do not match
DTSTART.

Original patch written by Jochen.Trumpf@anu.edu.au.
Related: bug 434599
FIXED-IN: 5.17.0

M  +9    -3    src/calendarview.cpp

https://invent.kde.org/pim/korganizer/commit/551d46c276bddb735386787d0141c83888695c44