classification
Title: A bug in datetime.astimezone() method
Type: behavior Stage: resolved
Components: Extension Modules Versions: Python 3.6, Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: belopolsky Nosy List: BGuo1, belopolsky, berker.peksag, python-dev, tim.peters, vstinner
Priority: normal Keywords: patch

Created on 2016-03-23 05:25 by belopolsky, last changed 2016-03-25 19:52 by belopolsky. This issue is now closed.

Files
File name Uploaded Description Edit
issue26616.diff belopolsky, 2016-03-23 18:26 review
bguo.patch BGuo1, 2016-03-24 05:09 review
Messages (8)
msg262239 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-03-23 05:25
With TZ=America/New_York,

>>> from datetime import *
>>> u = datetime(2015, 11, 1, 5, tzinfo=timezone.utc)
>>> t = u.astimezone()
>>> print(t)
2015-11-01 01:00:00-04:00
>>> print(t.astimezone())
2015-11-01 00:00:00-05:00

which is wrong - the second call to astimezone() should not change the timezone.  Note that pure python code does not have this bug.  (Try setiing sys.module['_datetime'] = None before running the code above.)
msg262240 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-03-23 05:27
See also #9527.
msg262295 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-03-23 18:34
This bug affects versions starting at 3.3.  Can someone advise to what versions the patch should be applied?
msg262296 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2016-03-23 18:38
3.3 and 3.4 are in security-fix-only mode: https://docs.python.org/devguide/devcycle.html#summary So this can be fixed in 3.5 and default branches.
msg262328 - (view) Author: Brian Guo (BGuo1) * Date: 2016-03-24 05:09
From the datetime documentation of astimezone(): 
https://docs.python.org/3.5/library/datetime.html#datetime.datetime.astimezone :

'If called without arguments (or with tz=None) the system local timezone is assumed. The tzinfo attribute of the converted datetime instance will be set to an instance of timezone with the zone name and offset obtained from the OS.'

You are correct in saying that there is an error in this implementation, but it is not that the second call should not change the timezone. Rather, the first call should have changed the timezone from UTC to America/New_York, or EST/EDT. When you made your first astimezone() call, (t = u.astimezone()), it was made without a tzinfo parameter, and should result in t's timzeone being EST by the documentation.

I have provided a patch that successfully adheres to this documentation. On changing the method, some of the tests failed; I have changed those tests to pass on the correct implementation of the method.
msg262450 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-03-25 18:26
> When you made your first astimezone() call, (t = u.astimezone()),
> it was made without a tzinfo parameter, and should result in t's
> timezeone being EST by the documentation.

No, u in my test case was selected to be right before the "fall-back" time.  The clocks in New York are moved back at 2am local, or 6am UTC.  You can verify that with zdump:

$ zdump -v America/New_York | grep 2015 | grep Nov
America/New_York  Sun Nov  1 05:59:59 2015 UTC = Sun Nov  1 01:59:59 2015 EDT isdst=1
America/New_York  Sun Nov  1 06:00:00 2015 UTC = Sun Nov  1 01:00:00 2015 EST isdst=0

so 5am UTC is 1 hour before the transition and is correctly translated to EDT by astimezone().
msg262452 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-03-25 19:47
New changeset 361a92204d4a by Alexander Belopolsky in branch '3.5':
Issue#26616:Fixed a bug in datetime.astimezone() method.
https://hg.python.org/cpython/rev/361a92204d4a
msg262453 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-03-25 19:52
The fix was applied to default in c9bc6614a652 but I got the commit message wrong.  I will not attempt to fix it (not sure it is even possible in hg.)
History
Date User Action Args
2016-03-25 19:52:12belopolskysetmessages: + msg262453
2016-03-25 19:48:53belopolskysetstatus: open -> closed
resolution: fixed
stage: commit review -> resolved
2016-03-25 19:47:39python-devsetnosy: + python-dev
messages: + msg262452
2016-03-25 19:18:44belopolskysetstage: patch review -> commit review
2016-03-25 19:18:35belopolskysetversions: - Python 3.3, Python 3.4
2016-03-25 18:26:50belopolskysetmessages: + msg262450
2016-03-24 05:09:04BGuo1setfiles: + bguo.patch
nosy: + BGuo1
messages: + msg262328

2016-03-23 18:38:07berker.peksagsetnosy: + berker.peksag
messages: + msg262296
2016-03-23 18:34:28belopolskysetmessages: + msg262295
versions: + Python 3.3, Python 3.4
2016-03-23 18:26:09belopolskysetfiles: + issue26616.diff

nosy: + tim.peters, vstinner
assignee: belopolsky
keywords: + patch
stage: needs patch -> patch review
2016-03-23 05:27:16belopolskysetmessages: + msg262240
2016-03-23 05:25:06belopolskycreate