-
Notifications
You must be signed in to change notification settings - Fork 269
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
time.localtime still uses original timezone information #494
Comments
All seem like basically the same thing? #89 specifically has a long discussion where we try to figure out what it SHOULD be doing. I would welcome someone tackling this and I will argue to spulec that any such person be given commit/merge access. I personally don't use freezegun anymore and have switched totally to time-machine, so I won't be spending more time with this. |
Yes #204 is indeed the exact same issue. Well, for my usecase i don't really care whether the passed time is utc or something else. |
If you're not using pypy, I strongly recommend you switch to time-machine. It's quite easy to switch in my experience. |
Yes, thats what i have done now. |
For folks migrating to time-machine because of this, you might wanna be aware of adamchainz/time-machine#325 (comment) |
When the time is frozen,
datetime.datetime.now()
anddatetime.datetime.utcnow()
return the same value, indicating that the timezone in this scenario is utc.However,
time.localtime()
does not return the same value asdatetime.datetime.now()
anymore.time.localtime()
still takes into account the actual timezone of the system.Minimal example:
Output:
The text was updated successfully, but these errors were encountered: