Message152774
| 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:42 | SamB | set | recipients:
+ SamB |
| 2012年02月06日 20:59:41 | SamB | set | messageid: <1328561981.97.0.928015101931.issue13957@psf.upfronthosting.co.za> |
| 2012年02月06日 20:59:41 | SamB | link | issue13957 messages |
| 2012年02月06日 20:59:41 | SamB | create |
|