New submission from Samuel Bronson <naes...@gmail.com>: This is what I'm seeing:
>>> import email.utils >>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 +0000') (2001, 11, 9, 1, 8, 47, 0, 1, -1, 0) >>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 -0000') (2001, 11, 9, 1, 8, 47, 0, 1, -1, 0) But RFC 5322 says: > minutes). The form "+0000" SHOULD be used to indicate a time zone at > Universal Time. Though "-0000" also indicates Universal Time, it is > used to indicate that the time was generated on a system that may be > in a local time zone other than Universal Time and that the date-time > contains no information about the local time zone. (As does RFC 2822, which RFC 5322 obsoletes.) And the documentation for email.utils.parsedate_tz is: > Performs the same function as parsedate(), but returns either None or a > 10-tuple; the first 9 elements make up a tuple that can be passed directly to > time.mktime(), and the tenth is the offset of the date’s timezone from UTC > (which is the official term for Greenwich Mean Time) [1]. If the input string > has no timezone, the last element of the tuple returned is None. Note that > indexes 6, 7, and 8 of the result tuple are not usable. So it seems like I should have seen: >>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 -0000') (2001, 11, 9, 1, 8, 47, 0, 1, -1, None) ---------- components: Library (Lib) messages: 152774 nosy: SamB priority: normal severity: normal status: open title: parsedate_tz doesn't distinguish -0000 from +0000 type: behavior versions: Python 2.7 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13957> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com