I would suggest improvement of mktime_tz to use calendar.timegm internally instead of time.mktime. The problem is that on Windows mktime_tz fails with "mktime argument out of range" for this code:

mktime_tz(parsedate_tz('Thu, 1 Jan 1970 00:00:00 GMT'))

if user is in GMT+X timezone. Obviously, "Thu, 1 Jan 1970 00:00:00 GMT" is not out of range. But because mktime_tz uses internally time.mktime which takes into the account local time (and local timezone) and then compensate for the timeline, out of range condition happens. I would suggest such implementation:

def mktime_tz(data):
    """Turn a 10-tuple as returned by parsedate_tz() into a UTC timestamp."""
    if data[9] is None:
        # No zone info, so localtime is better assumption than GMT
        return time.mktime(data[:8] + (-1,))
    else:
        t = calendar.timegm(data[:8] + (0,))
        return t - data[9]

It does not raise and exception, and it is also much cleaner: directly using GMT function and not localtime with timezone compensation.

I think that what is going to happen is that both of these functions are going to be deprecated in favor of functions that use datetimes.

That said, this might be a worthwhile as a bug fix.  I'm adding Alexander as nosy to see what he thinks.  (mktime_tz is located in email.utils, with the source in Lib/email/_parseaddr.py).

> That said, this might be a worthwhile as a bug fix.

I think this is a reasonable bug fix.  Note that apart from OS-dependent date range, some mktime implementations reportedly don't support tm_isdst values other than -1.

New changeset ffc048f43a70 by Alexander Belopolsky in branch '3.2':
Issue #14653: email.utils.mktime_tz() no longer relies on system
http://hg.python.org/cpython/rev/ffc048f43a70

New changeset 9f88c38318ac by Alexander Belopolsky in branch 'default':
Issue #14653: email.utils.mktime_tz() no longer relies on system
http://hg.python.org/cpython/rev/9f88c38318ac

New changeset a283563c8cc4 by Alexander Belopolsky in branch '2.7':
Issue #14653: email.utils.mktime_tz() no longer relies on system
http://hg.python.org/cpython/rev/a283563c8cc4