I'd look also into dateutil.parser.parse and feedparser._parse_date On Thursday, September 6, 2012 1:34:18 PM UTC-7, John Nagle wrote: > On 9/6/2012 12:51 PM, Paul Rubin wrote: > > > John Nagle <na...@animats.com> writes: > > >> There's an iso8601 module on PyPi, but it's abandoned; it hasn't been > > >> updated since 2007 and has many outstanding issues. > > > > > > Hmm, I have some code that uses ISO date/time strings and just checked > > > to see how I did it, and it looks like it uses iso8601-0.1.4-py2.6.egg . > > > I don't remember downloading that module (I must have done it and > > > forgotten). I'm not sure what its outstanding issues are, as it works > > > ok in the limited way I use it. > > > > > > I agree that this functionality ought to be in the stdlib. > > > > Yes, it should. There's no shortage of implementations. > > PyPi has four. Each has some defect. > > > > PyPi offers: > > > > iso8601 0.1.4 Simple module to parse ISO 8601 dates > > iso8601.py 0.1dev Parse utilities for iso8601 encoding. > > iso8601plus 0.1.6 Simple module to parse ISO 8601 dates > > zc.iso8601 0.2.0 ISO 8601 utility functions > > > > Unlike CPAN, PyPi has no quality control. > > > > Looking at the first one, it's in Google Code. > > > > http://code.google.com/p/pyiso8601/source/browse/trunk/iso8601/iso8601.py > > > > The first bug is at line 67. For a timestamp with a "Z" > > at the end, the offset should always be zero, regardless of the default > > timezone. See "http://en.wikipedia.org/wiki/ISO_8601". > > The code uses the default time zone in that case, which is wrong. > > So don't call that code with your local time zone as the default; > > it will return bad times. > > > > Looking at the second one, it's on github: > > > > https://github.com/accellion/iso8601.py/blob/master/iso8601.py > > > > Giant regular expressions! The code to handle the offset > > is present, but it doesn't make the datetime object a > > timezone-aware object. It returns a naive object in UTC. > > > > The third one is at > > > > https://github.com/jimklo/pyiso8601plus > > > > This is a fork of the first one, because the first one is abandonware. > > The bug in the first one, mentioned above, isn't fixed. However, if > > a time zone is present, it does return an "aware" datetime object. > > > > The fourth one is the Zope version. This brings in the pytz > > module, which brings in the Olsen database of named time zones and > > their historical conversion data. None of that information is > > used, or necessary, to parse ISO dates and times. Somebody > > just wanted the pytz.fixedOffset() function, which does something > > datetime already does. > > > > (For all the people who keep saying "use strptime", that doesn't > > handle time zone offsets at all.) > > > > John Nagle
-- http://mail.python.org/mailman/listinfo/python-list