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 roysmith
Recipients Alexander.Belopolsky, Arfrever, belopolsky, cvrebert, nagle, r.david.murray, roysmith
Date 2012-09-09.15:06:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1347203210.73.0.88674021706.issue15873@psf.upfronthosting.co.za>
In-reply-to
Content
I see I mis-stated my example.  When I wrote:

s = str(d1)
d2 = datetime.datetime(s)
assert d1 == d2

what I really meant was:

s = d1.isoformat()
d2 = datetime.datetime(s)
assert d1 == d2

But, now I realize that while that is certainly an absolute lower bound, it's almost certainly not sufficient.  The most common use case I see on a daily basis is parsing strings that look like "2012-09-07T23:59:59+00:00".  This is also John Nagle's original use case from the cited mailing list thread:

> I want to parse standard ISO date/time strings such as
>     2012-09-09T18:00:00-07:00

Datetime.isoformat() returns something that matches the beginning of that, but doesn't have the time zone offset.  And it's the offset that makes strptime() not usable as a soluation, because "%z" isn't portable.

If we don't satisfy the "2012-09-07T23:59:59+00:00" case, then we won't have really done anything useful.
History
Date User Action Args
2012-09-09 15:06:50roysmithsetrecipients: + roysmith, belopolsky, nagle, Arfrever, r.david.murray, cvrebert, Alexander.Belopolsky
2012-09-09 15:06:50roysmithsetmessageid: <1347203210.73.0.88674021706.issue15873@psf.upfronthosting.co.za>
2012-09-09 15:06:50roysmithlinkissue15873 messages
2012-09-09 15:06:49roysmithcreate