They both return raw tuples, which are not very intuitive to interpret:

>>> email.utils.parsedate_tz("Wed, 15 Sep 2010 09:53:50 -0700 (PDT)")
(2010, 9, 15, 9, 53, 50, 0, 1, -1, -25200)

It would be much better if they returned some kind of namedtuple, which would preserve backwards compatibility but with much better readability and usability.

Note that parsedate() could also return the existing time.struct_time type (which is compatible with a 9-tuple):
http://docs.python.org/library/time.html#time.struct_time

+1

By the way, while as mentioned in the docs “indexes 6, 7, and 8 of the result tuple are not usable”, perhaps it would be time to fix it? (at least for 6 and 7, aka. wday and yday)

If the changes I propose in issue9909 are implemented (briefly: a calendar.dayofyear() function), the following patch (with documentation and tests) should fill in the missing fields in the returned tuple.

Note that the email._parseaddr module now depends on the calendar module.

I was not clear: the patch I provided REQUIRES the function I provided in issue9909. But I don't know how to change the "Dependencies" field in Roundup.

I've added #9909 as a dependency, but IMO it is less likely to be accepted than this feature request.

On this issue, I would much rather see email package to start using datetime objects to represent time rather than named or unnamed tuples.

> On this issue, I would much rather see email package to start using
> datetime objects to represent time rather than named or unnamed tuples.

I agree on the principle, but I don't know if it's acceptable with regards to compatibility. It's up to David and Barry to decide.

It does make sense, and email6 is like Python 3 in the sense that backward compatibility is not a priority.

Yes, email6 should make use of datetime objects.  For email5 Antoine's proposal is better, but the question is will it happen before 3.2 beta :)

I'm assigning this to myself because I'm assigned on all email issues, but that shouldn't prevent someone from working on a patch implementing Antoine's suggestion.

Where does "email6" live?

http://launchpad.net/python-email6

Here's a patch for the python-email6 branch.

It seemed to make sense to remove parsedate_tz() and mktime_tz() here, since the parsedate() function now returns a datetime object, including timezone information (if it was parsed from the input string).

Also required updating several tests to work with the new return type, and removing a test that checked if the returned value of parsedate() (a time tuple) was "acceptable" for use with functions from the time module.

Thanks, Jeffrey.  I've applied your patch (with minor doc tweaks) to the email6 branch.

We ended up deciding to keep backward compatibility and add datetime support as a new API.  All of these changes are now checked in to default.  (See issue 665194, as well as issue 12586.)