This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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
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 2022-04-11 14:57 by admin. 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,))
        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/
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) (Python triager) 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

New changeset 9f88c38318ac by Alexander Belopolsky in branch 'default':
Issue #14653: email.utils.mktime_tz() no longer relies on system
msg163382 - (view) Author: Roundup Robot (python-dev) (Python triager) 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
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.
Date User Action Args
2022-04-11 14:57:29adminsetgithub: 58858
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