-
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
Datetime and Time packages do not have the same behavior when being frozen #535
Comments
Hi @folkvir! I created a standalone test case in #537 - if I'm understanding the problem correctly, that demonstrates the fact that there is indeed a bug here. I think the appropriate fix is to extend all FakeDatetime methods to use |
I'll try to look into it and create a pull request as soon as possible but I don't have a lot of time to spend outside my family and job. So if someone has more free time then go! |
@bblommers Ok after investigations I found calling
Increasing the call_stack_inspection_limit does not change anything. |
Update: I think I found the core of the bug; but it may be an artefact of the test setup because we locally import the |
Hello!
A few days ago a bug occured and we discover that the time were not frozen correctly in our tests. We reported the issue in pytest-freezer (pytest-dev/pytest-freezer#14) but after deeper investigations it seems that the function
_should_use_real_time
reports that we should use realtime when it should'nt.When using the 2 additional ignore elements
freezegun.configure("_pytest.runner", "_pytest.terminal")
(which are added to mitigate the bug on the pytest--durations
option) time functions return real time in teardown fixtures while datetime functions return correct mocked time. @wimglenn tracked this here pytest-dev/pytest-freezer#14 (comment)More precisely; the guilty ignore option is
_pytest.runner
. I see 3 possibilities (maybe more?):_should_use_real_time
; don't know if it is the right solution_pytest.runner
package we need to ignore; to work with the current code without breaking the--durations
option.time
package; just like thedatetime
packageThe text was updated successfully, but these errors were encountered: