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.

Author BGuo1
Recipients BGuo1, belopolsky, berker.peksag, tim.peters, vstinner
Date 2016-03-24.05:09:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1458796144.41.0.731099721677.issue26616@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2016-03-24 05:09:04BGuo1setrecipients: + BGuo1, tim.peters, belopolsky, vstinner, berker.peksag
2016-03-24 05:09:04BGuo1setmessageid: <1458796144.41.0.731099721677.issue26616@psf.upfronthosting.co.za>
2016-03-24 05:09:04BGuo1linkissue26616 messages
2016-03-24 05:09:03BGuo1create