dateutil >= 2.7.1 now internally forces compliance with RFC5545 Section 3.3.10

[jcriner-dev]

TestIcalendar.test_recurrence fails with dateutil >= 2.7.1. icalendar.RecurringComponent.getrruleset is trying to handle special UNTIL rule cases AFTER the rule is created by dateutil. However, dateutil.rrule >= 2.7.1 now forces compliance with RFC5545 Section 3.3.10 and in some cases the rule cannot be created and raises ValueError. It is unclear what, if anything, should be done (check UNTIL BEFORE the rule is created or rely on dateutil and update tests.py). More information can be found in code comments in pull request #111

icalendar.RecurringComponent.getrruleset:

                    value = line.value.replace('\\', '')
                    rule = rrule.rrulestr(
                        value, dtstart=dtstart,
                        # If dtstart has no time zone, `until`
                        # shouldn't get one, either:
                        ignoretz=isinstance(dtstart, datetime.date))
                    until = rule._until

                    if until is not None and isinstance(dtstart,
                                                        datetime.datetime) and \
                            (until.tzinfo != dtstart.tzinfo):

dateutil.rrule >= 2.7.1:

        if self._dtstart and self._until:
            if (self._dtstart.tzinfo is not None) != (self._until.tzinfo is not None):
                # According to RFC5545 Section 3.3.10:
                # https://tools.ietf.org/html/rfc5545#section-3.3.10
                #
                # > If the "DTSTART" property is specified as a date with UTC
                # > time or a date with local time and time zone reference,
                # > then the UNTIL rule part MUST be specified as a date with
                # > UTC time.
                raise ValueError(
                    'RRULE UNTIL values must be specified in UTC when DTSTART '
                    'is timezone-aware'
                )

[pganssle]

Regarding that last bit of code, I'm fairly certain that actually using the recurrence rule would have always triggered a bug, because this is only triggered if both DTSTART and UNTIL are populated and one has a time zone but the other doesn't. The change in 2.7.1 was just intended as an "eager fail". Is there an actual viable use case that this breaks?

[pganssle]

Oh I see, you were creating the rule and then modifying it if it failed this test. Hm...

[dvzrv]

This is a major blocker for packaging radicale on Arch Linux and will probably also have an effect on more software using it, such as khard. Radicale introduced a hard version pinning because of this, which is completely incompatible with a rolling release concept, such as the one Arch is build upon.

Would be awesome to have a fix to this, so the version pinning can be removed.

[pganssle]

@dvzrv radicale and khard are applications, not libraries, right? Presumably until this is fixed you can package them in virtual environments, that way they don't need to use the system-installed version of python-dateutil.