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 belopolsky
Recipients BGuo1, belopolsky, berker.peksag, tim.peters, vstinner
Date 2016-03-25.18:26:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1458930410.56.0.294813013962.issue26616@psf.upfronthosting.co.za>
In-reply-to
Content
> 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().
History
Date User Action Args
2016-03-25 18:26:50belopolskysetrecipients: + belopolsky, tim.peters, vstinner, berker.peksag, BGuo1
2016-03-25 18:26:50belopolskysetmessageid: <1458930410.56.0.294813013962.issue26616@psf.upfronthosting.co.za>
2016-03-25 18:26:50belopolskylinkissue26616 messages
2016-03-25 18:26:49belopolskycreate