Recurring events: instances with STATUS:CANCELLED synced as EXDATE

[akki42]

Hi all,

First of all: many thanks for the continuing work in DAVx5!

Second: I have read your FAQ on the limitations with recurring events. As I am reporting on a Nextcloud - Thunderbird - [Android / DAVx5 / Calendar app] mismatch, there might be many "culprits". That being said, I still believe this might be a DAVx5 bug?! ;-)

DAVx5 App version

I'm using the latest available DAVx⁵ version: 4.4.3.2-gplay

Android version and device/firmware type

LineageOS 21-20241115-NIGHTLY-gts4lv (Android 14/AP2A.240905.003.F1) on Samsung Tab S5e

Android calendar app
multiple, e.g. Etar (LineageOS version) or Fossify Calendar

Nextcloud version

30.0.2  (Calendar app: v5.0.1)

Thunderbird version

128.4.2esr 

Steps to reproduce

• Create recurring event (either via Nextcloud calendar app, Thunderbird, or Android calendar app)
• Set STATUS property of one instance of said recurring event to CANCELLED, either via Nextcloud calendar app or Thunderbird
• Sync the calendar on your device.

Actual result

Android Calendar apps will not show the cancelled instances of the recurring event.
Fossify Calendar ICS export shows cancelled instances as EXDATE.

Expected result

Android Calendar apps should show cancelled instances, with special marking, e.g. strike-through, if supported by app (e.g. Etar or Fossify Calendar as of recently).
Calendar app export should show cancelled instances as separate VEVENTs as in Nextcloud and Thunderbird export.

Further info

• I have attached the Nextcloud, Thunderbird, and Fossify Calendar ics exports of a test calendar. (Had to add .txt extension to upload.)
• The single event with status CANCELLED included in the test calendar is synced and shown properly.

[rfc2822]

This is known behavior and a feature: https://github.com/bitfireAT/ical4android/blob/d01dba06fcc57717cfc55d0ce6423538be37da7b/lib/src/main/kotlin/at/bitfire/ical4android/AndroidEvent.kt#L521

Some clients generate an EXDATE in this case and so it was requested....

[akki42]

Thanks for the info!

Could you please provide some more background on which clients / use cases require this behaviour? (Searching for EXDATE, I did not find any issues / discussions in the ical4android repo...)

For background:
Handling the STATUS property in Android calendar apps (displaying the STATUS, e.g. by strike-through, as a first step; allowing to change STATUS as a second step) has been requested for years (e.g. Etar-Group/Etar-Calendar#201, SimpleMobileTools/Simple-Calendar#808 and FossifyOrg/Calendar#145 (comment)).
Now that Etar and Fossify Calendar have implemented this (Etar: display only so far; Fossify Calendar: display and change), I am quite disappointed to learn that - at least for recurring events - a "mismatch" will remain between those apps and the Nextcloud and Thunderbird calendars, respectively.

More than just a mismatch in (not) displaying existing CANCELLED instances on Android, this - I believe - also leads to a quite surprising behavior when changing STATUS to CANCELLED (for a single instance of a recurring event) in Fossify Calendar:
First, the amended instance is shown in Fossify Calendar with strike-through (as expected); however, after a short time [I suppose: after syncing] this CANCELLED instance suddenly "disappears" (in Fossify Calendar, and also in Nextcloud and Thunderbird - ics then includes an EXDATE).

This rather defeats the purpose / a consistent UI between calendars...

[rfc2822]

Could you please provide some more background on which clients / use cases require this behaviour? (Searching for EXDATE, I did not find any issues / discussions in the ical4android repo...)

Unfortunately I don't know it by heart anymore.

However if you "delete" (or "remove") an occurrence in a Calendar app (lets say Etar), I'd expect the event to be "deleted" and not "cancelled". So calendars should set the EXDATE in my opinion. However they set CANCELLED…

So basically I think this is

• a question of user expectations (whether EXDATE or CANCELLED should be used, but EXDATE is the more simple variant because it doesn't require a separate exception event with a RECURRENCE-ID, and everything that reduces complexity avoid potential problems),
• a question of whether calendar apps like Etar could implement EXDATE properly, in which case we wouldn't have to change CANCELLED to EXDATE.