New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tizinfo.fromutc changed for tzinfo wih StdOffset=0, DstOffset=1 #67788
Comments
There's a difference in behaviour between the From what I can tell, it's the Python 3 one which is wrong, based on it no longer matching the sample implementation provided in the docs and on it appearing to report the wrong times for I've put the python script (and sample outputs) I used to investigate in a gist at https://gist.github.com/PeterJCLaw/d8bcc168d68acf066811#file-time_issues-py. The outputs there are for pythons 2.7.9 and 3.4.0. |
Peter, Can you attach your demo script to the issue? Better yet, is it possible to explain the issue without referring to 100 lines of code? |
Hi, Sorry for the overkill demo. I've attached a much shorter version, the key portion of which seems to be that, for the case of UK summer time the timezone, the tzinfo's This results in the delta between the two (which my understanding suggests equates to the non-dst offset of the timezone) is zero (which is right). The python implementations (both in datetime.py and in the docs) cope with this by checking the DST difference and applying this after the timezone adjustments have happened. From a look through the CPython implementation, it looks to me like it's checking the wrong value before applying the DST difference. Specifically, on line 3033 in Modules/_datetimemodule.c, it checks For the majority of timezones this happens to work since the standard offset is not 0 and it ends up doing the addition anyway (and no functionality is lost if the DST value is 0). Having tested changing the checked value to being dst rather than delta this does appear to fix this and all the existing tests still pass. Peter |
I am afraid you misunderstand how fromutc() method works. Note that you rarely need to call it directly: use astimezone() method to convert between timezones. |
I expect Peter is correct: the C fromutc() doesn't match the logic of the Python fromutc(), and there are no comments explaining why the C version changed the logic. The last 4 lines of his |
It looks like I introduced this bug ~ 5 years ago when I made a switch from integer minutes offset to an arbitrary timedelta. It's rather amazing that it took so long to discover it. |
Attaching a patch that should fix the issue. |
Patch looks good to me! Thanks :-) |
Thanks, Tim. Now I need to figure out how to commit to multiple branches. This goes to 3.4 through 3.6, right? or just to 3.5 and 3.6. |
Afraid that's a question for python-dev - I lost track of the active branches over year ago :-( |
I give up. Somehow my changes conflict with parent: 98335:0d3b64bbc82c and my knowledge of hg is not enough to get out. When are we switching to git? |
New changeset ff68705c56a8 by Alexander Belopolsky in branch '3.4': New changeset c706c062f545 by Alexander Belopolsky in branch '3.5': New changeset 4879c10ce982 by Alexander Belopolsky in branch 'default': New changeset cbcf82f92c25 by Alexander Belopolsky in branch '3.4': New changeset 848d665bc312 by Alexander Belopolsky in branch '3.5': |
OK, I have no idea how I managed to create two commits in 3.4 and 3.5 and loose the NEWS entry in the end. |
Awesome, thanks for fixing this. |
Thank you for your persistence and patience, Peter! It shouldn't have been this hard for you :-( |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: