Calendar sync crashes with NumberFormatException

AutoImport-werbung1975

I’m using Cyanogenmod M2 on a Nexus 5, but if I remember correctly the same problem occured in stock 4.4.2 as well.
The content of S27vWB4n4F53l642OG4bm0.ics:

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:20130503T195759Z
LAST-MODIFIED:20130503T195800Z
DTSTAMP:20131109T131332Z
UID:S27vWB4n4F53l642OG4bm0
SUMMARY:Simon 1966
STATUS:CONFIRMED
RRULE:FREQ=YEARLY;UNTIL=21001231;BYMONTHDAY=21;BYMONTH=1
DTSTART;VALUE=DATE:20130121
DTEND;VALUE=DATE:20130121
CLASS:PRIVATE
X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for LOCATION proper
 ty. Removing entire property:
SEQUENCE:0
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR

AutoImport-werbung1975

Just imported my whole ics-file to an owncloud instance and got errors, that 00001231T000000Z is not a date. So I checked the file and found:
CREATED:00001231T000000Z .Maybe thats related to the problem because in the logcat it said

01-29 01:47:43.576 E/DatabaseUtils(11605): java.lang.NumberFormatException: Invalid int: "T0"

rfc2822

Working on this… at least 3 problems so far:

Android bug: RRULE UNTIL component limited by 32-bit UNIX time → reported
Android bug: DURATION=0 sec causes the NumberFormatException from the report
So how to deal with DTSTART=DTEND all-day events, when setting DTEND is not allowed for recurring events and DURATION=0 crashes? DURATION=null works, but isn’t documented. DURATION=1 day would be wrong for “events on that day”.

It will need more time…

rfc2822

@werbung1975:

DTSTART;VALUE=DATE:20130121
DTEND;VALUE=DATE:20130121

Is this really a 0-second event on 21 Jan 2013? If it’s an all-day event on this day, the iCal would have to be

DTSTART;VALUE=DATE:20130121
DTEND;VALUE=DATE:20130122

because DTEND is non-inclusive. See http://permalink.gmane.org/gmane.comp.mozilla.devel.calendar/894

Could you please try whether OwnCloud generates DTEND=DTSTART or DTEND = DTSTART+1 when you create an all-day event for this day? In the first case, there would be an OwnCloud bug (aside to the DAVdroid, Android, … etc bugs related to this issue ;)).

AutoImport-dimentiyinfo

Hi rfc2822,

Unfortunately, wide-known Yahoo! Calendar service generated such iCAL records several last days (definitely. I exported events as *.ics and reviewed them).
It may be Yahoo’s problem technically, but really it’s user’s problem.

AutoImport-dimentiyinfo

It’s how event looks like in Yahoo!:
yahoocal

AutoImport-dimentiyinfo

It’s corresponding *.ics file contents (sorry for dumping, do not know how attach file here):
BEGIN:VCALENDAR
PRODID://Yahoo//Calendar//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
SUMMARY:Test event
CLASS:PUBLIC
DTSTART;VALUE=DATE:20140210
DTEND;VALUE=DATE:20140210
PRIORITY:0
SEQUENCE:0
STATUS:CONFIRMED
UID:69eee550-ce11-4717-92f3-840f7748114a
DTSTAMP:20140208T123846Z
ORGANIZER;CN=Dmitriy Popkov;SENT-BY=“mailto:#####@yahoo.com”:mailt
o:#####@yahoo.com
TRANSP:OPAQUE
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/London
TZURL:http://tzurl.org/zoneinfo/Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19810329T010000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:19961027T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:-000115
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:18471201T000000
RDATE:18471201T000000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19160521T020000
RDATE:19160521T020000
RDATE:19170408T020000
RDATE:19180324T020000
RDATE:19190330T020000
RDATE:19200328T020000
RDATE:19210403T020000
RDATE:19220326T020000
RDATE:19230422T020000
RDATE:19240413T020000
RDATE:19250419T020000
RDATE:19260418T020000
RDATE:19270410T020000
RDATE:19280422T020000
RDATE:19290421T020000
RDATE:19300413T020000
RDATE:19310419T020000
RDATE:19320417T020000
RDATE:19330409T020000
RDATE:19340422T020000
RDATE:19350414T020000
RDATE:19360419T020000
RDATE:19370418T020000
RDATE:19380410T020000
RDATE:19390416T020000
RDATE:19400225T020000
RDATE:19460414T020000
RDATE:19470316T020000
RDATE:19480314T020000
RDATE:19490403T020000
RDATE:19500416T020000
RDATE:19510415T020000
RDATE:19520420T020000
RDATE:19530419T020000
RDATE:19540411T020000
RDATE:19550417T020000
RDATE:19560422T020000
RDATE:19570414T020000
RDATE:19580420T020000
RDATE:19590419T020000
RDATE:19600410T020000
RDATE:19610326T020000
RDATE:19620325T020000
RDATE:19630331T020000
RDATE:19640322T020000
RDATE:19650321T020000
RDATE:19660320T020000
RDATE:19670319T020000
RDATE:19680218T020000
RDATE:19720319T020000
RDATE:19730318T020000
RDATE:19740317T020000
RDATE:19750316T020000
RDATE:19760321T020000
RDATE:19770320T020000
RDATE:19780319T020000
RDATE:19790318T020000
RDATE:19800316T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:19161001T030000
RDATE:19161001T030000
RDATE:19170917T030000
RDATE:19180930T030000
RDATE:19190929T030000
RDATE:19201025T030000
RDATE:19211003T030000
RDATE:19221008T030000
RDATE:19230916T030000
RDATE:19240921T030000
RDATE:19251004T030000
RDATE:19261003T030000
RDATE:19271002T030000
RDATE:19281007T030000
RDATE:19291006T030000
RDATE:19301005T030000
RDATE:19311004T030000
RDATE:19321002T030000
RDATE:19331008T030000
RDATE:19341007T030000
RDATE:19351006T030000
RDATE:19361004T030000
RDATE:19371003T030000
RDATE:19381002T030000
RDATE:19391119T030000
RDATE:19451007T030000
RDATE:19461006T030000
RDATE:19471102T030000
RDATE:19481031T030000
RDATE:19491030T030000
RDATE:19501022T030000
RDATE:19511021T030000
RDATE:19521026T030000
RDATE:19531004T030000
RDATE:19541003T030000
RDATE:19551002T030000
RDATE:19561007T030000
RDATE:19571006T030000
RDATE:19581005T030000
RDATE:19591004T030000
RDATE:19601002T030000
RDATE:19611029T030000
RDATE:19621028T030000
RDATE:19631027T030000
RDATE:19641025T030000
RDATE:19651024T030000
RDATE:19661023T030000
RDATE:19671029T030000
RDATE:19711031T030000
RDATE:19721029T030000
RDATE:19731028T030000
RDATE:19741027T030000
RDATE:19751026T030000
RDATE:19761024T030000
RDATE:19771023T030000
RDATE:19781029T030000
RDATE:19791028T030000
RDATE:19801026T030000
RDATE:19811025T020000
RDATE:19821024T020000
RDATE:19831023T020000
RDATE:19841028T020000
RDATE:19851027T020000
RDATE:19861026T020000
RDATE:19871025T020000
RDATE:19881023T020000
RDATE:19891029T020000
RDATE:19901028T020000
RDATE:19911027T020000
RDATE:19921025T020000
RDATE:19931024T020000
RDATE:19941023T020000
RDATE:19951022T020000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:BDST
DTSTART:19410504T020000
RDATE:19410504T020000
RDATE:19420405T020000
RDATE:19430404T020000
RDATE:19440402T020000
RDATE:19450402T020000
RDATE:19470413T020000
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19410810T030000
RDATE:19410810T030000
RDATE:19420809T030000
RDATE:19430815T030000
RDATE:19440917T030000
RDATE:19450715T030000
RDATE:19470810T030000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19681027T000000
RDATE:19681027T000000
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:+0000
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:19960101T000000
RDATE:19960101T000000
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

AutoImport-werbung1975

The event was created on an old Nokia phone from 2007 synced with gmail via active sync protokoll (Nokia Mail for Exchange) and than exported from gmail as ics-File. It is supposed to be a whole day event. I think those events where sometimes changed to events from 00:00 to 23:59. So I guess its not an owncloud issue.

AutoImport-werbung1975

I also tried the following app, but it crashes as well:
https://github.com/gggard/AndroidCaldavSyncAdapater/issues/157
because got confused by the names of the apps, I wrote the bug-report to Marten Gajda from CalDAV-Sync. He told me that in his app such events with DTSTART = DTEND get a duration of one day (Thank you Marten).

rfc2822

Thanks for the info.

I’m going rewriting some DtStart/DtEnd logic (also introducing better unit tests).

For now, my proposed “solution” is that all-day events must always last at least one day (DTEND >= DTSTART+1). If DTEND is missing (“events on that day”) or DTEND = DTSTART (invalid all-day events like those posted above), DAVdroid will set DTEND := DTSTART +1 (because that’s the only value that makes sense) and thus prevent Android from crashing.

By the way, I wonder when CalDav-Sync goes open-source…

AutoImport-werbung1975

Hey the new version does not crash anymore, thanks! However those events with a UNTIL-date still show up only once. Do you want me to create a new issue or are you waiting for it to be fixed in android?

rfc2822

@werbung1975 Can you please try to set the UNTIL-Date to something before 2038 in the iCalendar?