The datetime package is too eager to reject nonconforming VCALENDAR-format files.  The particular issue I encountered is related to time zones.  RFC 5545 clearly states that the DTSTART field is required.  However, there are situations where DTSTART isn't strictly necessary because the zone in question doesn't observe daylight-savings time and never has.

For example, I have a VCALENDAR file that was generated by a program that omits DTSTART for such zones.  Here's an example:

BEGIN:VTIMEZONE
TZID:America/Phoenix
X-LIC-LOCATION:America/Phoenix
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0700
TZNAME:Ariz
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0700
TZNAME:Ariz
END:STANDARD
END:VTIMEZONE

Clearly, this file violates RFC 5445, and I have reported that fact to the program's maintainer (who will fix the problem soon).  Nevertheless, feeding an ICS file to datetime._parse_rfc with this error causes a ValueError exception, which makes the VCALENDAR file unreadable.

In keeping with Postel's law ("Be conservative in what you do, be liberal in what you accept from others"), _parse_rfc should attempt to accept VCALENDAR files whenever it is possible to make sense of them.  Thus, for example:

    if not founddtstart:
        rrulelines.append('DTSTART:19000101T020000')

The above could be improved a bit, for example by still rejecting entries in which the standard and daylight sections had different offsets (although even then it seems valid to assume a DTSTART in the distant past).

Although the dtstart issue is the one that prompted this report, I also noticed the following in _parse_rfc:

    if name == "BEGIN":
        if value in ("STANDARD", "DAYLIGHT"):
            # Process component
            pass
        else:
            raise ValueError("unknown component: "+value)

Again, there's an opportunity to be more robust here.  One could issue a warning message, but then ignore the unknown component.

In both cases (and I suspect numerous others), halting parsing is an extreme response to various errors, since it leaves the user of the package with no way to process a nonconforming file.  That's especially problematic since VCALENDAR files are generated by so many different programs, many of which are written by programmers who haven't bothered to read RFC 5445--or who have read it but then made some minor mistake that produces broken files.