Failed to load item ... invalid recurrence rules in VEVENT

[ecbftw]

I'm attempting to upgrade from Radicale 1.1.x to 2.1.8. I followed the migration steps, exporting from the 1.1 version to a new database, and then I ran the new version with the --verify-storage command. Most of my ~1400 calendar entries verify fine, but about 15 of them fail to verify, all with the same error message. Here is the exception for one of them:

[7fd15a83c700] ERROR: Invalid item '16EC2639-ECD4-41DC-A999-A2BEDF055D8F.ics' in 'shared/home.ics': Failed to load item '16EC2639-ECD4-41DC-A999-A2BEDF055D8F.ics' in 'shared/home.ics': invalid recurrence rules in VEVENT
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/radicale/storage.py", line 162, in check_and_sanitize_item
    component.rruleset
  File "/usr/local/lib/python3.5/dist-packages/vobject/icalendar.py", line 453, in getrruleset
    ignoretz=isinstance(dtstart, datetime.date))
  File "/usr/local/lib/python3.5/dist-packages/dateutil/rrule.py", line 1664, in __call__
    return self._parse_rfc(s, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/dateutil/rrule.py", line 1547, in _parse_rfc
    tzinfos=tzinfos)
  File "/usr/local/lib/python3.5/dist-packages/dateutil/rrule.py", line 1506, in _parse_rfc_rrule
    return rrule(dtstart=dtstart, cache=cache, **rrkwargs)
  File "/usr/local/lib/python3.5/dist-packages/dateutil/rrule.py", line 461, in __init__
    'RRULE UNTIL values must be specified in UTC when DTSTART '
ValueError: RRULE UNTIL values must be specified in UTC when DTSTART is timezone-aware

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/radicale/storage.py", line 1391, in _get_with_metadata
    tag=self.get_meta("tag"))
  File "/usr/local/lib/python3.5/dist-packages/radicale/storage.py", line 165, in check_and_sanitize_item
    component.name) from e
ValueError: invalid recurrence rules in VEVENT

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/radicale/storage.py", line 906, in exception_cm
    yield
  File "/usr/local/lib/python3.5/dist-packages/radicale/storage.py", line 886, in discover
    yield collection.get(href)
  File "/usr/local/lib/python3.5/dist-packages/radicale/storage.py", line 1255, in get
    item, metadata = self._get_with_metadata(href, verify_href=verify_href)
  File "/usr/local/lib/python3.5/dist-packages/radicale/storage.py", line 1397, in _get_with_metadata
    (href, self.path, e)) from e
RuntimeError: Failed to load item '16EC2639-ECD4-41DC-A999-A2BEDF055D8F.ics' in 'shared/home.ics': invalid recurrence rules in VEVENT

Many of the calendar entries I don't care about, but some I do, since they were recently created. I'm attaching the ics file that caused the above exception. 16EC2639-ECD4-41DC-A999-A2BEDF055D8F.ics.txt

My questions are:

• How can I hack these files in the short term to make them digestible by Radicale?
• Is this a bug in Radicale that needs to be addressed?
• Is this a one-time issue with the export/import process, or will this issue crop up with new events created by the same CalDAV clients I have been using all along?

[ecbftw]

As I dig deeper into this, I'm focusing on this bit:
ValueError: RRULE UNTIL values must be specified in UTC when DTSTART is timezone-aware

The RRULE in the file (with some context) is:

DTSTART;TZID=America/Los_Angeles:20170428T140000
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC
CREATED:20170409T211157Z
RRULE:FREQ=MONTHLY;INTERVAL=1;UNTIL=20171125T075959Z;BYDAY=-1FR

Isn't 20171125T075959Z already in UTC time with that trailing Z?

Ok, so now I see dateutil/dateutil#620 talking about this, but I still don't know the best work-around...

[ecbftw]

More info in dateutil/dateutil#652

[Unrud]

Is this a bug in Radicale that needs to be addressed?

No, it's a bug in VObject: skarim/vobject#112

You can either patch VObject (skarim/vobject#111) or downgrade dateutil to an older version, that doesn't trigger the bug in VObject.

This is a duplicate of #764.

Is this a one-time issue with the export/import process, or will this issue crop up with new events created by the same CalDAV clients I have been using all along?

It's not a one-time issue.

Isn't 20171125T075959Z already in UTC time with that trailing Z?

Yes.

[ecbftw]

Ok, thanks much for clearing that up for me.

I tried patching VObject by changing that one key line in the (skarim/vobject#111) patch from:

ignoretz=isinstance(dtstart, datetime.date))

to:

ignoretz=(isinstance(dtstart, datetime.date) and not isinstance(dtstart, datetime.datetime)))

and it seems to have fixed the issue for now. (At least, it isn't blowing up on those files now.)

[thehaven]

Same issue, @ecbftw's fix worked for me as well. Thanks

[Unrud]

Fixed by 5cd43ac