-
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
host timezone can't be faked #299
Comments
possible workaround - set env vaiable |
based on @IaroslavR 's comment, I wrote the following context manager which does the job in my testsuite: @contextlib.contextmanager
def mock_tz(new_tz):
old_tz = os.environ.get('TZ')
os.environ['TZ'] = new_tz
time.tzset()
try:
yield
finally:
if old_tz is not None:
os.environ['TZ'] = old_tz
else:
del os.environ['TZ']
time.tzset() I went with a standalone utility so that I could set the time in any TZ and have my fake system time in a specific TZ. Not sure if this is a common use case. Any how, maybe someone will have a brilliant idea on how to provide a nice API inside freezegun. Cheers |
I also think this is a problem. It appears the |
I also believe this is a mistake. I would argue that it's well worth breaking peoples existing tests if they rely on the current behavior in these situations. |
Relatedly, I believe the freezegun implementation violates the spec of datetime.astimezone, which says:
However, freezegun sets
Unless I'm missing something? |
"utcnow" returns a naive timestamp, which effectively subtracts an hour from the local time, which is what we're trying to represent. datetime.fromtimestamp(datetime.utcnow().timestamp()) datetime.datetime(2022, 4, 24, 8, 8, 29, 576299) datetime.fromtimestamp(datetime.now().timestamp()) datetime.datetime(2022, 4, 24, 9, 9, 5, 365402) Using "now" is correct. Because reasoning about naive times can be so confusing, this also makes all of them timezone-aware e.g. datetime.utcnow().isoformat() '2022-04-26T07:13:24.259928' datetime.now().astimezone().isoformat() '2022-04-26T08:13:58.523714+01:00' Using "astimezone" converts the datetime object to the specified timezone by interpreting it in the implicit local timezone. Tests now set explicit timestamps or zone-aware datetimes to make it clear what actual time is being tested. Unfortunately freeze_gun is not a reliable tool for this [^1][^2] so this commit replaces it. In the case of the Octopus sensor, we are effectively converting a date to a time so we also need to lock the system timezone to ensure test stability. time-machine needs Python 3.9+ to do this [^3]. [^1]: spulec/freezegun#348 [^2]: spulec/freezegun#299 [^3]: https://github.com/adamchainz/time-machine#timezone-mocking
fake_tz.py:
Output:
pytz
- can't resolve tz for same reason, looks like bug inpytz
itselfarrow
- tz resolved,naive time
correct, tzinfo incorrect(not affected at all)tz_offset
arg -naive time
incorrect, tzinfo incorrect(not affected at all)The text was updated successfully, but these errors were encountered: