OK thanks, please follow up there.
Tasks: COMPLETED Date cannot be cast to DateTime
DAVDroid is working well with CalDAV/CardDAV provided by Radicale, except when synchronising Tasks. Upon the first sync, the tasks were downloaded, but subsequent syncs fail with:
java.lang.ClassCastException: net.fortuna.ical4j.model.Date cannot be cast to net.fortuna.ical4j.model.DateTime
Full backtrace here: http://pastebin.com/PD2XLy2e
In the future, please always provide the full debug info. Line numbers from a stack trace are only useful when they can be associated to a certain file version, which can be determined from the DAVdroid version.
It seems like the problem is at
builder .withValue(Tasks.COMPLETED, task.completedAt.getDateTime().getTime())
The cause of your problem seems to be that COMPLETED is of type DATE in your iCalendar. However, COMPLETED must be a DATE-TIME and not a DATE. DAVdroid expects a DATE-TIME and wants to get its UNIX time, so there’s a cast exception when it tries to evaluate the DATE as DATE-TIME.
Solution: Please fix your task so that COMPLETED is a DATE-TIME, as specified in RFC 5545.
However, DAVdroid may be more resilient against this and convert DATE to DATE-TIME with 00:00 time in this case.
Sorry about missing data from backtrace, complete version here: http://pastebin.com/1fXJDpxD
The events appear to be mix of DATE-TIME and DATEs, however it does state it’s a DATE as appropriate:
% grep ^COMPLETED linton.ics
I believe that the events that have DATEs have been submitted by https://sourceforge.net/projects/outlookcaldavsynchronizer/ and the DATE-TIME ones by Lightning. Fixing the tasks on the CalDAV server will only fix them as they currently stand, the problem is likely to reoccur with newly completed tasks.
I’ll take up the issue with the authors of outlookcaldavsynchronizer, but as you say, for resilience DAVdroid should be more flexible about what it reads.
Just to flag the issue here, this appears to be a problem with the https://sourceforge.net/projects/dday-ical/ library where it substitutes a DATE if time is 0000. And the reason time is 0000 is because Outlook doesn’t log a time. There may be other users of this library, so if DAVdroid could be more resilient it would be good.
@sborrill Can you please report the bug to DDay.iCal?
Resilience implemented in ical4android 19ef2603edc7a28bce1b9ea1f7fa11ca89234dc0.
Times will now be extracted from DATE values, too. This means that they are not at 00:00, but the time zone offset will be applied. However, DAVdroid will not produce an exception anymore. To get correct values, use the correct DATE-TIME format.