Skip to content
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

Open
lbckmnn opened this issue Feb 21, 2023 · 5 comments
Open

time.localtime still uses original timezone information #494

lbckmnn opened this issue Feb 21, 2023 · 5 comments

Comments

@lbckmnn
Copy link

lbckmnn commented Feb 21, 2023

When the time is frozen, datetime.datetime.now() and datetime.datetime.utcnow() return the same value, indicating that the timezone in this scenario is utc.
However, time.localtime() does not return the same value as datetime.datetime.now() anymore. time.localtime() still takes into account the actual timezone of the system.

Minimal example:

import datetime
import time

import freezegun

if __name__ == "__main__":
    target_time = datetime.datetime.now()
    print(target_time)
    print(time.localtime())
    print(datetime.datetime.utcnow())

    with freezegun.freeze_time(target_time):
        print(datetime.datetime.now())
        print(time.localtime(time.time()))
        print(datetime.datetime.utcnow())

Output:

2023-02-21 14:54:39.964024
time.struct_time(tm_year=2023, tm_mon=2, tm_mday=21, tm_hour=14, tm_min=54, tm_sec=39, tm_wday=1, tm_yday=52, tm_isdst=0)
2023-02-21 13:54:39.964071
2023-02-21 14:54:39.964024
time.struct_time(tm_year=2023, tm_mon=2, tm_mday=21, tm_hour=15, tm_min=54, tm_sec=39, tm_wday=1, tm_yday=52, tm_isdst=0)
2023-02-21 14:54:39.964024

@lbckmnn lbckmnn changed the title Possible DST/Timezone issues time.localtime still uses original timezone information Feb 21, 2023
@boxed
Copy link
Contributor

boxed commented Feb 21, 2023

#348
#204
#89

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.

@lbckmnn
Copy link
Author

lbckmnn commented Feb 21, 2023

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.
The problem is, that datetime.datetime.now() returns the utc time once frozen and time.localtime() doesn't. That is really inconsistent.
For my usecase, I need datetime.datetime.now() and time.localtime()to return the same time.

@boxed
Copy link
Contributor

boxed commented Feb 21, 2023

If you're not using pypy, I strongly recommend you switch to time-machine. It's quite easy to switch in my experience.

@lbckmnn
Copy link
Author

lbckmnn commented Feb 21, 2023

Yes, thats what i have done now.
Thanks for the suggestion!

@edgarrmondragon
Copy link

For folks migrating to time-machine because of this, you might wanna be aware of adamchainz/time-machine#325 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants