homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author SamB
Recipients SamB
Date 2012年02月06日.20:59:41
SpamBayes Score 1.802003e-12
Marked as misclassified No
Message-id <1328561981.97.0.928015101931.issue13957@psf.upfronthosting.co.za>
In-reply-to
Content
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)
History
Date User Action Args
2012年02月06日 20:59:42SamBsetrecipients: + SamB
2012年02月06日 20:59:41SamBsetmessageid: <1328561981.97.0.928015101931.issue13957@psf.upfronthosting.co.za>
2012年02月06日 20:59:41SamBlinkissue13957 messages
2012年02月06日 20:59:41SamBcreate

AltStyle によって変換されたページ (->オリジナル) /