Describe the bug
When jtx Board modifies a task that was originally created without a VTIMEZONE component (using UTC-only timestamps such as DTSTAMP:20260430T130447Z), it writes the task back to the CalDAV server with an added VTIMEZONE block containing an invalid UTC offset:
- TZOFFSETFROM:0000
- TZOFFSETTO:0000
RFC 5545 §3.6.5 requires a sign prefix — the valid form is +0000. The missing + causes DAVx⁵'s ical4j parser to throw InvalidICalendarException and abort the sync for the entire calendar collection. Every subsequent sync fails until the affected .ics is manually repaired or deleted on the server.
Related to #172 — but distinct: in that issue the VTIMEZONE component is absent entirely; here the component is present but contains a malformed offset value.
To Reproduce
- Have a task in a CalDAV calendar that uses UTC-only timestamps and contains no VTIMEZONE component (e.g. created by a third-party client).
- Let jtx Board sync and display that task.
- Edit and save the task in jtx Board.
- Inspect the .ics written back to the server — a VTIMEZONE block is now present with TZOFFSETFROM:0000.
- Trigger a DAVx⁵ sync — it fails with InvalidICalendarException on that resource.
Expected behavior
When writing back a UTC-based task, jtx Board should either:
- emit a valid VTIMEZONE block using TZOFFSETFROM:+0000 / TZOFFSETTO:+0000, or
- omit the VTIMEZONE block entirely and keep all datetime values in the Z (UTC) suffix form, which is fully valid per RFC 5545.
Screenshots
None
DAVx⁵ debug log excerpt:
EXCEPTION at.bitfire.synctools.exception.InvalidICalendarException: Couldn't parse iCalendar
Caused by: net.fortuna.ical4j.data.ParserException: Error at line 9:
Invalid ID for ZoneOffset, invalid format: 0000
Caused by: j$.time.DateTimeException: Invalid ID for ZoneOffset, invalid format: 0000
at net.fortuna.ical4j.model.property.TzOffsetFrom.setValue(...)
REMOTE RESOURCE
https:///remote.php/dav/calendars///<ics_filename>.ics
Device and version
- Device: Samsung Galaxy S23 Ultra (SM-S918B)
- Android version: Android 16 (BP2A.250605.031.A3.S918BXXS9EZCI)
- jtx Board version: 2.16.00.gplay (216000015)
- Downloaded from: Google Play
Describe the bug
When jtx Board modifies a task that was originally created without a VTIMEZONE component (using UTC-only timestamps such as DTSTAMP:20260430T130447Z), it writes the task back to the CalDAV server with an added VTIMEZONE block containing an invalid UTC offset:
RFC 5545 §3.6.5 requires a sign prefix — the valid form is +0000. The missing + causes DAVx⁵'s ical4j parser to throw InvalidICalendarException and abort the sync for the entire calendar collection. Every subsequent sync fails until the affected .ics is manually repaired or deleted on the server.
Related to #172 — but distinct: in that issue the VTIMEZONE component is absent entirely; here the component is present but contains a malformed offset value.
To Reproduce
Expected behavior
When writing back a UTC-based task, jtx Board should either:
Screenshots
None
DAVx⁵ debug log excerpt:
EXCEPTION at.bitfire.synctools.exception.InvalidICalendarException: Couldn't parse iCalendar
Caused by: net.fortuna.ical4j.data.ParserException: Error at line 9:
Invalid ID for ZoneOffset, invalid format: 0000
Caused by: j$.time.DateTimeException: Invalid ID for ZoneOffset, invalid format: 0000
at net.fortuna.ical4j.model.property.TzOffsetFrom.setValue(...)
REMOTE RESOURCE
https:///remote.php/dav/calendars///<ics_filename>.ics
Device and version