[issue26616] A bug in datetime.astimezone() method

2016-03-25 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: 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.) -- ___ Python tracker

[issue26616] A bug in datetime.astimezone() method

2016-03-25 Thread Alexander Belopolsky
Changes by Alexander Belopolsky : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker ___

[issue26616] A bug in datetime.astimezone() method

2016-03-25 Thread Roundup Robot
Roundup Robot added the comment: 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 -- nosy: +python-dev ___ Python tracker

[issue26616] A bug in datetime.astimezone() method

2016-03-25 Thread Alexander Belopolsky
Changes by Alexander Belopolsky : -- stage: patch review -> commit review ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue26616] A bug in datetime.astimezone() method

2016-03-25 Thread Alexander Belopolsky
Changes by Alexander Belopolsky : -- versions: -Python 3.3, Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue26616] A bug in datetime.astimezone() method

2016-03-25 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: > 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.

[issue26616] A bug in datetime.astimezone() method

2016-03-23 Thread Brian Guo
Brian Guo added the comment: >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 in

[issue26616] A bug in datetime.astimezone() method

2016-03-23 Thread Berker Peksag
Berker Peksag added the comment: 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. -- nosy: +berker.peksag ___ Python tracker

[issue26616] A bug in datetime.astimezone() method

2016-03-23 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: This bug affects versions starting at 3.3. Can someone advise to what versions the patch should be applied? -- versions: +Python 3.3, Python 3.4 ___ Python tracker

[issue26616] A bug in datetime.astimezone() method

2016-03-23 Thread Alexander Belopolsky
Changes by Alexander Belopolsky : -- assignee: -> belopolsky keywords: +patch nosy: +haypo, tim.peters stage: needs patch -> patch review Added file: http://bugs.python.org/file42262/issue26616.diff ___ Python tracker

[issue26616] A bug in datetime.astimezone() method

2016-03-22 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: See also #9527. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue26616] A bug in datetime.astimezone() method

2016-03-22 Thread Alexander Belopolsky
New submission from Alexander Belopolsky: 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