classification
Title: Improve mktime_tz to use calendar.timegm instead of time.mktime
Type: behavior Stage: resolved
Components: email Versions: Python 3.2, Python 3.3, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: belopolsky Nosy List: barry, belopolsky, jwilk, martin.panter, mitar, python-dev, r.david.murray
Priority: normal Keywords:

Created on 2012-04-23 20:33 by mitar, last changed 2013-06-17 15:24 by jwilk. This issue is now closed.

Messages (8)
msg159074 - (view) Author: Mitar (mitar) Date: 2012-04-23 20:33
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.
msg159171 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-04-24 16:49
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).
msg163296 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2012-06-20 21:19
> 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.
msg163381 - (view) Author: Roundup Robot (python-dev) Date: 2012-06-22 00:49
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
msg163382 - (view) Author: Roundup Robot (python-dev) Date: 2012-06-22 00:57
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
msg191325 - (view) Author: Jakub Wilk (jwilk) Date: 2013-06-17 12:15
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. :)
msg191338 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-06-17 14:09
Since this issue has been closed, it would be great if you'd open a new issue just for the doc change.
msg191347 - (view) Author: Jakub Wilk (jwilk) Date: 2013-06-17 15:24
Fair enough, filed as issue #18243.
History
Date User Action Args
2013-06-17 15:24:37jwilksetmessages: + msg191347
2013-06-17 14:09:17r.david.murraysetmessages: + msg191338
2013-06-17 12:15:43jwilksetnosy: + jwilk
messages: + msg191325
2012-06-22 00:59:25belopolskysetstatus: open -> closed
resolution: fixed
stage: commit review -> resolved
2012-06-22 00:57:51python-devsetmessages: + msg163382
2012-06-22 00:49:14python-devsetnosy: + python-dev
messages: + msg163381
2012-06-20 21:19:07belopolskysetassignee: belopolsky
messages: + msg163296
stage: commit review
2012-05-24 14:56:52r.david.murraysetassignee: r.david.murray -> (no value)

components: + email, - Library (Lib)
nosy: + barry
2012-05-09 08:12:11martin.pantersetnosy: + martin.panter
2012-04-24 16:49:05r.david.murraysetversions: + Python 3.2, Python 3.3
nosy: + r.david.murray, belopolsky

messages: + msg159171

assignee: r.david.murray
2012-04-23 20:33:31mitarcreate