On 30/08/2014 00:35, Skip Montanaro wrote:
It doesn't look like Gustavo Niemeyer is actively working on python-dateutil. Tomi Pievilaeinen is listed on PyPI as the author, but I have no email address for him, so I'm tossing this message in a bottle out into the Gulf Stream in hopes that Gustavo or Tomi notice it.I'm using imaplib to download and process messages from Gmail. I use dateutil.parser.parse to parse the Date header into a datetime object, then use the most recent date I've seen to decide where to start up on the next run. Every once in awhile, I encountered a Date header I couldn't parse. The couple I've seen so far have the same problem: two different spellings of the timezone offset. Sat, 23 Aug 2014 16:42:08 -0700 (GMT-07:00) Fri, 22 Aug 2014 18:14:46 -0700 (GMT-07:00) Discarding the extra timezone info in the "(GMT-07:00)" suffix makes the string parseable: >>> dateutil.parser.parse('Sat, 23 Aug 2014 16:42:08 -0700 (GMT-07:00)') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Users/skip/.local/lib/python2.7/site-packages/dateutil/parser.py", line 748, in parse return DEFAULTPARSER.parse(timestr, **kwargs) File "/Users/skip/.local/lib/python2.7/site-packages/dateutil/parser.py", line 310, in parse res, skipped_tokens = self._parse(timestr, **kwargs) TypeError: 'NoneType' object is not iterable >>> dateutil.parser.parse('Sat, 23 Aug 2014 16:42:08 -0700') datetime.datetime(2014, 8, 23, 16, 42, 8, tzinfo=tzoffset(None, -25200)) I suppose I could work around the problem, but it occurs so rarely, it's just easier to discard that particular date. This would seem to be low priority for Tomi and Gustavo, but thought that if it was an easy change it might be worthwhile. Skip
The Gulf Stream is not likely to reach a large enough audience, I suggest you expand the numbers by trying the North Atlantic Drift.
-- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
