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 ztane
Recipients Anders.Hovmöller, Arfrever, Eric.Hanchrow, Roman.Evstifeev, SilentGhost, aymeric.augustin, barry, belopolsky, berker.peksag, cvrebert, davydov, deronnax, eric.araujo, flying sheep, gvanrossum, jcea, jstasiak, jwilk, karlcow, kirpit, martin.panter, mcepl, mihaic, nagle, pbryan, perey, piotr.dobrogost, r.david.murray, roysmith, shanmbic, tim.peters, vstinner, ztane
Date 2016-07-16.06:49:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
"Be conservative in what you do, be liberal in what you accept from others" they say. Also Z as a timezone designator is also widely used in iso 8601 timestamps. I believe the effort should be made to *parse* *any/all* of the ISO 8601 supported time-zone codes with one conversion, the list is not that long, just 'Z', HH, HH:MM, HHMM, longest match. Literal 'Z' really does not need to be supported for *output* at all, but for input, please.

Otherwise this will still go down the road of iso8601 library, which just tries to support all the YYmmddTHHMMSS.FFFFFFzzzz variants. It uses regular expressions to parse the dates as it is faster than trying N different formats with `strptime`
Date User Action Args
2016-07-16 06:49:01ztanesetrecipients: + ztane, gvanrossum, tim.peters, barry, jcea, roysmith, belopolsky, nagle, vstinner, jwilk, mcepl, eric.araujo, Arfrever, r.david.murray, davydov, cvrebert, karlcow, SilentGhost, perey, flying sheep, mihaic, aymeric.augustin, Roman.Evstifeev, berker.peksag, martin.panter, piotr.dobrogost, kirpit, Anders.Hovmöller, jstasiak, Eric.Hanchrow, deronnax, pbryan, shanmbic
2016-07-16 06:49:01ztanesetmessageid: <>
2016-07-16 06:49:01ztanelinkissue24954 messages
2016-07-16 06:49:00ztanecreate