Failure processing 2022-03-07T::

[kaie]

A calendar found in the wild contains date time values of the following format: 2022-03-07T::

While this is clearly a bad format, it seems the calendar code attempts to be lenient, so it might be good to attempt to handle this, too.

Originally reported at https://bugzilla.mozilla.org/show_bug.cgi?id=1754412

[kaie]

pull request: #516

[twalling]

I was seeing this error this week when trying to parse this ICS file http://www.calendarlabs.com/ical-calendar/ics/76/US_Holidays.ics

It's different than the ones I've seen from google which include a VALUE=DATE string with each DTSTART and DTEND. Whenever I got to the point of trying to access those properties and the value was being wrapped in an ICAL.Time model I was seeing an error like you described above, 2021-01-01T:: in this case.

[edd189]

I was seeing this error this week when trying to parse this ICS file http://www.calendarlabs.com/ical-calendar/ics/76/US_Holidays.ics

It's different than the ones I've seen from google which include a VALUE=DATE string with each DTSTART and DTEND. Whenever I got to the point of trying to access those properties and the value was being wrapped in an ICAL.Time model I was seeing an error like you described above, 2021-01-01T:: in this case.

Reporting same issue here. Throwing an error when the DTSTART or DTEND does not contain a time component. This appears to be allowed by the ics standard: https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.2

Value Type: The default value type is DATE-TIME. The value type can be set to a DATE value type. ("DATE-TIME" / "DATE")

[kewisch]

Let's continue in #620