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 p-ganssle
Recipients mariocj89, martin.panter, p-ganssle, pablogsal
Date 2017-10-19.13:56:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1508421371.76.0.213398074469.issue31800@psf.upfronthosting.co.za>
In-reply-to
Content
This seems very useful to me. I very frequently advise people *against* using dateutil.parser (despite my conflict of interest as maintainer of dateutil) for well-known formats, but the problem frequently comes up of, "what should I do when I have date created by isoformat()?", to which there's no clean satisfying answer other than, "use dateutil.parser even though you know the format."

I think the strptime page that Mario linked to is evidence that the %z directive is *intended* to match against -HH:MM, and so that might be the most "standard" solution.

That said, I somewhat prefer the granularity of the GNU date extensions %z, %:z and %::z, since this allows downstream users to be stricter about what they are willing to accept. I think either approach is defensible, but that *something* should be done soon, preferably for the 3.7 release.
History
Date User Action Args
2017-10-19 13:56:11p-gansslesetrecipients: + p-ganssle, martin.panter, mariocj89, pablogsal
2017-10-19 13:56:11p-gansslesetmessageid: <1508421371.76.0.213398074469.issue31800@psf.upfronthosting.co.za>
2017-10-19 13:56:11p-gansslelinkissue31800 messages
2017-10-19 13:56:11p-gansslecreate