Invalid icalendar file entry triggers DAVDroid exception report

[jelmer]

One of my calendar items triggers exception reports in DAVDroid. This is probably because something (timezone?) in the calendar entry is invalid, but it would be nice if DAVDroid could handle it more gracefully or tell me what specifically is invalid about the entry.

This is the exception:

— BEGIN DEBUG INFO —
SYNCHRONIZATION INFO
Synchronization phase: 9
Account name: ACCOUNTNAME
Authority: com.android.calendar

LOCAL RESOURCE:
LocalEvent=[eTag=fe01ba7c8d4ac4748335c898b3b6654f4331f411, fileName=unknown-20061003T150938Z-12683-1000-1-0@.ics, weAreOrganizer=true, calendar=at.bitfire.davdroid.resource.LocalCalendar@65510d7, event=Event=[alarms=[], attendees=[], classification=CLASS:PUBLIC, color=null, description=null, dtEnd=DTEND;TZID=/softwarestudio.org/Olson_20011030_5/Europe/Amsterdam:20061003T170000, dtStart=DTSTART;TZID=/softwarestudio.org/Olson_20011030_5/Europe/Amsterdam:20061003T150000, duration=null, exDates=[], exRule=null, exceptions=[], lastModified=LAST-MODIFIED:20061003T151024, location=THELOCATION, opaque=true, organizer=null, rDates=[], rRule=null, recurrenceId=null, status=null, summary=Overleg + planning, unknownProperties=[CREATED:20061003T151006
], sequence=3, uid=20061003T150938Z-12683-1000-1-0@, shadow$klass=class at.bitfire.ical4android.Event, shadow$monitor=0], id=null, shadow$klass=class at.bitfire.davdroid.resource.LocalEvent, shadow$monitor=0]

REMOTE RESOURCE:
BASEURL/calendar/unknown-20061003T150938Z-12683-1000-1-0%40.ics

EXCEPTION:
java.util.NoSuchElementException
at java.util.Collections$EmptyIterator.next(Collections.java:4235)
at java.util.Collections.min(Collections.java:677)
at net.fortuna.ical4j.model.TimeZoneLoader.addTransitionRules(TimeZoneLoader.java:174)
at net.fortuna.ical4j.model.TimeZoneLoader.generateTimezoneForId(TimeZoneLoader.java:164)
at net.fortuna.ical4j.model.TimeZoneLoader.loadVTimeZone(TimeZoneLoader.java:109)
at net.fortuna.ical4j.model.TimeZoneRegistryImpl.getTimeZone(TimeZoneRegistryImpl.java:181)
at at.bitfire.ical4android.MiscUtils.androidifyTimeZone(MiscUtils.kt:30)
at at.bitfire.ical4android.AndroidEvent.buildEvent(AndroidEvent.kt:482)
at at.bitfire.davdroid.resource.LocalEvent.buildEvent(LocalEvent.kt:76)
at at.bitfire.ical4android.AndroidEvent.add(AndroidEvent.kt:381)
at at.bitfire.ical4android.AndroidEvent.add(AndroidEvent.kt:368)
at at.bitfire.davdroid.syncadapter.CalendarSyncManager.processVEvent(CalendarSyncManager.kt:200)
at at.bitfire.davdroid.syncadapter.CalendarSyncManager.downloadRemote(CalendarSyncManager.kt:163)
at at.bitfire.davdroid.syncadapter.SyncManager.performSync(SyncManager.kt:155)
at at.bitfire.davdroid.syncadapter.CalendarsSyncAdapterService$SyncAdapter.sync(CalendarsSyncAdapterService.kt:55)
at at.bitfire.davdroid.syncadapter.SyncAdapterService$SyncAdapter.onPerformSync(SyncAdapterService.kt:85)
at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:272)

SOFTWARE INFORMATION
Package: at.bitfire.davdroid
Version: 1.9.2-gplay (186) from 4 Nov 2017
Installed from: com.android.vending
JB Workaround installed: no

CONNECTIVITY (at the moment)
Active connection: WiFi, CONNECTED

CONFIGURATION
Power saving disabled: yes
android.permission.READ_CONTACTS permission: granted
android.permission.WRITE_CONTACTS permission: granted
android.permission.READ_CALENDAR permission: granted
android.permission.WRITE_CALENDAR permission: granted
org.dmfs.permission.READ_TASKS permission: granted
org.dmfs.permission.WRITE_TASKS permission: granted
System-wide synchronization: automatically
Account: ACCOUNT
Address book sync. interval: 240 min
Calendar sync. interval: 240 min
OpenTasks sync. interval: 240 min
WiFi only: false
[CardDAV] Contact group method: CATEGORIES
[CalDAV] Time range (past days): 90
Manage calendar colors: true

SQLITE DUMP
android_metadata
| locale |
| en_GB |

services
| _id | accountName | service | principal |
…
| 2 | ACCOUNT | caldav | BASEURL |

sqlite_sequence
| name | seq |
| services | 2 |
| homesets | 3 |
| collections | 15 |

homesets
| _id | serviceID | url |
…
| 3 | 2 | BASEURL |

collections
| _id | serviceID | url | readOnly | displayName | description | color | timezone | supportsVEVENT | supportsVTODO | sync | type | source |
…
| 10 | 2 | BASEURL/calendars/calendar/ | 0 | calendar | Personal calendar.<LF> | -16738048 | <null> | 1 | 1 | 1 | CALENDAR | <null> |
…

---

SYSTEM INFORMATION
Android version: 8.0.0 (OPR4.170623.009)
Device: LGE Nexus 5X (bullhead)

— END DEBUG INFO —

(LOCATION, ACCOUNT and BASEURL replaced)

Problematic ical file attached.

0_1510088423219_unknown-20061003T150938Z-12683-1000-1-0@.ics

[rfc2822]

Hello,

Yes, this event seems to have an invalid time zone. I recommend to fix the VTIMEZONE or simply create the event again with a valid VTIMEZONE.

be nice if DAVDroid could handle it more gracefully or tell me what specifically is invalid about the entry.

I agree. However,

• I’m afraid handling that gracefully could lead to events with wrong time, which is absolutely a bad idea, because you may miss an important event. In my opinion, it’s better to know that there’s something wrong with the event, so you an fix it.
• unfortunately, DAVdroid has no capabilities to repair events and to be honest, it’s not an iCalendar repair tool. It uses ical4j for parsing and when ical4j fails to parse an event, there are not many options for DAVdroid.

So, if you have a specific idea how to improve that specific case, please let us know. But I’d stay away from assuming anything about timezones, which will cause events to have the wrong time in the calendar.

[jelmer]

@rfc2822 Yep, that makes sense.

It would be great if a broken file like this wouldn’t block synchronization. I’m not very familiar with the sync infrastructure in Android, but would it be possible to e.g. notify the user that a broken file was found and whether they would like to Remove or Ignore it?

[rfc2822]

@jelmer Theoretically, yes. But this would make the sync interactive and completely turn around how DAVdroid is intended to work (in the background, without user interaction). I guess the best option is to repair the event manually. Also, servers shouldn’t send invalid events, so maybe they could be repaired there.

Or better yet, fix the client which has created the event so that it doesn’t create invalid events.