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

freezegun doesn't take timezones into account in some cases #309

Closed
wolph opened this issue Sep 19, 2019 · 4 comments
Closed

freezegun doesn't take timezones into account in some cases #309

wolph opened this issue Sep 19, 2019 · 4 comments

Comments

@wolph
Copy link

wolph commented Sep 19, 2019

Simple testcase:

import time
import datetime

from freezegun import freeze_time


def test():
    a = time.mktime(datetime.datetime.now().timetuple())
    b = time.time()
    print(int(b - a))


with freeze_time():
    print('With freezegun:')
    test()


print('Without freezegun:')
test()

Results for me (I'm in GMT+2):

With freezegun:
7200
Without freezegun:
0
wolph added a commit to wolph/python-progressbar that referenced this issue Sep 19, 2019
@wolph
Copy link
Author

wolph commented Sep 19, 2019

A workaround for the issue:

   # The timezone offset in seconds, add 10 seconds to make sure we don't
    # accidently get the wrong hour
    offset_seconds = (datetime.now() - datetime.utcnow()).seconds + 10
    offset_hours = int(offset_seconds / 3600)

    freeze_time = freezegun.freeze_time(tz_offset=offset_hours)

@spulec
Copy link
Owner

spulec commented Sep 24, 2019

By default, freezegun will freeze to the UTC time instead of the system's timezone so I think this is expected behavior.

I believe this issue is a dupe of #89, but let me know if you don't think that is the case.

@wolph
Copy link
Author

wolph commented Sep 24, 2019

I believe it's similar but different. That issue could also fix this issue, but for now the biggest problem is the inconsistency that some methods do and others do not take the timezone into account.

The issue is that if I replace datetime.now with datetime.utcnow, it breaks without freezegun

@spulec
Copy link
Owner

spulec commented Sep 24, 2019

Okay. I am going to close this in favor of #89 then. As noted there, there are some backward-incompatibilities we would have to make to proceed.

@spulec spulec closed this as completed Sep 24, 2019
rlconsult added a commit to rlconsult/python-progress that referenced this issue May 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants