New submission from Geoff Kuenning <ge...@cs.hmc.edu>:

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.

----------
messages: 304944
nosy: gkuenning
priority: normal
severity: normal
status: open
title: datetime violates Postel's law

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31864>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to