ParseException on VCALENDAR created by Thunderbird

[lewoberst]

Problem scope

• I'm sure that this is a DAVx⁵ problem.

App version

• I'm using the latest available DAVx⁵ version.

Android version and device/firmware type

Android 16 (Pixel 6)

Steps to reproduce

Client: DAVx5 version 4.5.9-gplay (405090005)
Server: radicale version 3.1.8-2 on Debian Linux

I created the following entry using Mozilla Thunderbird yesterday, file creation timestamp is 2026-02-18 9:29:18.688000581 +0000. The file's mtime is the same. The error appeared some hours later on my mobile device. It is not possible to attach ics files, so I'll provide it inline:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:STANDARD
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:b9cce6c6-5d05-4129-9960-95942f35bb4b
DTSTART;VALUE=DATE:20240724
DTEND;VALUE=DATE:20240725
CLASS:PUBLIC
CREATED:20240722T125031Z
DTSTAMP:20260218T093131Z
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20240807
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20241030
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20241225
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20250319
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20250806
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20251029
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20251224
LAST-MODIFIED:20260218T093131Z
RRULE:FREQ=WEEKLY;INTERVAL=2
SEQUENCE:9
SUMMARY:Meeting
TRANSP:TRANSPARENT
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Meeting
TRIGGER:-PT15M
END:VALARM
X-MOZ-GENERATION:51
X-MOZ-LASTACK:20260218T093027Z
X-MOZ-SNOOZE-TIME-1733910300000000:20241211T094913Z
X-MOZ-SNOOZE-TIME-1737539100000000:20250122T094336Z
X-MOZ-SNOOZE-TIME-1752050700000000:20250709T083909Z
X-MOZ-SNOOZE-TIME-1760517900000000:20251015T085825Z
END:VEVENT
END:VCALENDAR

Actual result

DAVx5 displayed ParseException without further details about where that exception occured within the above entry.

While investigating the issue I accidentally closed the error screen and I don't see a way to reopen the latest error. So I cannot provide full debug information, sorry for that. Explicit resync in the client does not trigger the error again.

Expected result

No response

Further info

No response

[lewoberst]

It occured again for the same b9cce6c6-5d05-4129-9960-95942f35bb4b event. Now I got the debug-info and attached it.

debug-info.txt

[ArnyminerZ]

I believe this is caused by the recurrence exceptions (EXDATE):

EXDATE;TZID=Europe/Berlin;VALUE=DATE:20240807
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20241030
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20241225
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20250319
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20250806
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20251029
EXDATE;TZID=Europe/Berlin;VALUE=DATE:20251224

According to RFC5545@3.2.19:

when either a DATE-TIME or TIME value type is specified and when the value is neither a UTC or a "floating" time

If TZID is specified, it must given DATE-TIME or TIME, DATE is not allowed.

I don't know why Thunderbird is creating this ICS, but I'm pretty sure it's not rfc-compliant.

[rfc2822]

👍🏻 I can confirm that parsing the given iCalendar with ical4j (I just added it to Ical4jTest) causes

Error at line 46:TimeZone is not applicable to current value
net.fortuna.ical4j.data.ParserException: Error at line 46:TimeZone is not applicable to current value
	at app//net.fortuna.ical4j.data.CalendarParserImpl.parse(CalendarParserImpl.java:172)
	at app//net.fortuna.ical4j.data.CalendarBuilder.build(CalendarBuilder.java:191)
...
Caused by: java.lang.UnsupportedOperationException: TimeZone is not applicable to current value
	at net.fortuna.ical4j.model.property.DateListProperty.setTimeZone(DateListProperty.java:137)
	at net.fortuna.ical4j.data.DefaultContentHandler.resolveTimezones(DefaultContentHandler.java:244)
	at net.fortuna.ical4j.data.DefaultContentHandler.endCalendar(DefaultContentHandler.java:97)
	at net.fortuna.ical4j.data.CalendarParserImpl.parseCalendar(CalendarParserImpl.java:140)
	at net.fortuna.ical4j.data.CalendarParserImpl.parseCalendarList(CalendarParserImpl.java:194)
	at net.fortuna.ical4j.data.CalendarParserImpl.parse(CalendarParserImpl.java:163)
	... 45 more

which is because ical4j doesn't expect a date to have a TZID. However it could also just ignore it.

There's already an issue for that (even with the same timezone Europe/Berlin): ical4j/ical4j#362.

I wonder whether this is already fixed in ical4j 4.x (we want to switch from 3.x to 4.x very soon). If yes, the problem will just disappear. If not, we could post more information in the issue mentioned above.

[rfc2822]

Just tested with ical4j 4.x and the problem doesn't occur anymore. So this should be automatically fixed when we update to ical4j 4.x (very soon): bitfireAT/synctools#112