Improve mktime_tz to use calendar.timegm instead of time.mktime

[mitar]

BPO	14653
Nosy	@warsaw, @abalkin, @jwilk, @bitdancer, @mitar, @vadmium

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/abalkin'
closed_at = <Date 2012-06-22.00:59:25.468>
created_at = <Date 2012-04-23.20:33:31.259>
labels = ['type-bug', 'expert-email']
title = 'Improve mktime_tz to use calendar.timegm instead of time.mktime'
updated_at = <Date 2013-06-17.15:24:37.991>
user = 'https://github.com/mitar'

bugs.python.org fields:

activity = <Date 2013-06-17.15:24:37.991>
actor = 'jwilk'
assignee = 'belopolsky'
closed = True
closed_date = <Date 2012-06-22.00:59:25.468>
closer = 'belopolsky'
components = ['email']
creation = <Date 2012-04-23.20:33:31.259>
creator = 'mitar'
dependencies = []
files = []
hgrepos = []
issue_num = 14653
keywords = []
message_count = 8.0
messages = ['159074', '159171', '163296', '163381', '163382', '191325', '191338', '191347']
nosy_count = 7.0
nosy_names = ['barry', 'belopolsky', 'jwilk', 'r.david.murray', 'mitar', 'python-dev', 'martin.panter']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue14653'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']

[mitar]

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.

[bitdancer]

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).

[abalkin]

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.

[python-dev]

New changeset ffc048f43a70 by Alexander Belopolsky in branch '3.2':
Issue bpo-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 bpo-14653: email.utils.mktime_tz() no longer relies on system
http://hg.python.org/cpython/rev/9f88c38318ac

[python-dev]

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

[jwilk]

The documentations says "Minor deficiency: mktime_tz() interprets the first 8 elements of tuple as a local time and then compensates for the timezone difference. This may yield a slight error around changes in daylight savings time, though not worth worrying about for common use."

Now that this bug has been fixed, this no longer true. Please update the documentation. :)

[bitdancer]

Since this issue has been closed, it would be great if you'd open a new issue just for the doc change.