Invalid icalendar file entry triggers DAVDroid exception report
-
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
-
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.
-
@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?
-
@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.