Parsing ISO date/time strings - where did the parser go?

[Miki Tebeka]

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 <nagle at 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