New submission from Geoff Kuenning <[email protected]>:
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 <[email protected]>
<https://bugs.python.org/issue31864>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
