A bug in datetime.astimezone() method

[abalkin]

BPO	26616
Nosy	@tim-one, @abalkin, @vstinner, @berkerpeksag
Files	issue26616.diff bguo.patch

^{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 2016-03-25.19:48:53.080>
created_at = <Date 2016-03-23.05:25:06.170>
labels = ['extension-modules', 'type-bug']
title = 'A bug in datetime.astimezone() method'
updated_at = <Date 2016-03-25.19:52:12.175>
user = 'https://github.com/abalkin'

bugs.python.org fields:

activity = <Date 2016-03-25.19:52:12.175>
actor = 'belopolsky'
assignee = 'belopolsky'
closed = True
closed_date = <Date 2016-03-25.19:48:53.080>
closer = 'belopolsky'
components = ['Extension Modules']
creation = <Date 2016-03-23.05:25:06.170>
creator = 'belopolsky'
dependencies = []
files = ['42262', '42267']
hgrepos = []
issue_num = 26616
keywords = ['patch']
message_count = 8.0
messages = ['262239', '262240', '262295', '262296', '262328', '262450', '262452', '262453']
nosy_count = 6.0
nosy_names = ['tim.peters', 'belopolsky', 'vstinner', 'python-dev', 'berker.peksag', 'BGuo1']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue26616'
versions = ['Python 3.5', 'Python 3.6']

[abalkin]

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

[abalkin]

See also bpo-9527.

[abalkin]

This bug affects versions starting at 3.3. Can someone advise to what versions the patch should be applied?

[berkerpeksag]

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.

[BGuo1]

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.

[abalkin]

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

[python-dev]

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

[abalkin]

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