Kozea
Make "can't compare offset-naive and offset-aware datetimes" non-fatal
This turns what used to result in a 500 error on loading calendars with repetition rules that make vobject trigger comparison errors (typically imported from old calendars, possibly created using faulty software) into at worst ignoring the event when fetching a time slice; showing a warning in the logs.
This showed up when I tried to migrate an almost 10-year-long calendar into radicale. Quite possibly the files are even faulty in the sense that time zones are missing where there should be some, but that shouldn't bring down the whole calendar (as it so far did).
Might help close #758 and #956 / #957 (as they seem to be the ones suffering from this error cropping up in imports); others (#925, #1146) may profit from a generalization of this.
Note that there may also be an underlying bug in the vobject library, but that shouldn't stand in the way of fixing this here where it can catch all subtle variations of it. That can happen in parallel; if vobject catches all of these cases, no warnings will be shown any more out of radicale.
Looking through unrelated other import errors, for a more stringent handling it may be an option to add a check to check_and_sanitize_items to look for whether all is timezoned or not as it should be.
Given that the vobject repetition iterator may still be faulty somewhere or we may miss a check, I still think that silencing them here is a practical thing; the more that's done in the checking stage, the fewer warnings will show, and maybe they can be turned to escalate when they haven't come up for a time.
I've found it easier to just fix the offending files -- in all cases, the EXDATE;VALUE=date:20120101 lines were missing a Z at the end, when all the other dates had proper time zones attached.