[New-bugs-announce] [issue13957] parsedate_tz doesn't distinguish -0000 from +0000

[Samuel Bronson]

New submission from Samuel Bronson <naesten at 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 <report at bugs.python.org>
<http://bugs.python.org/issue13957>
_______________________________________