test_datetime.now(tz) does not behave the same as datetime.now(tz)
Closed this issue · 5 comments
This could well be my misunderstanding, but I'm trying to understand the nuances around mocking datetime and timezone-aware times.
From the documentation:
If you pass in a tz parameter to now() it will be applied to the value before it is returned in the same way as it would by datetime.datetime.now().
This does not appear to be the case.
datetime.now() from the standard library behaves like this (with BST, i.e. UTC+1 as my local timezone):
datetime.now()
datetime.datetime(2020, 10, 16, 11, 45, 36, 650854)
datetime.now(pytz.UTC)
datetime.datetime(2020, 10, 16, 10, 45, 47, 445272, tzinfo=<UTC>)
Note that now(UTC) returns a time that is an hour behind, as expected.
test_datetime behaves like this:
td = test_datetime(datetime.now(), delta=0)
td.now()
datetime.datetime(2020, 10, 16, 11, 46, 7, 40605)
td.now(pytz.UTC)
datetime.datetime(2020, 10, 16, 11, 46, 7, 40605, tzinfo=<UTC>)
Both calls return the same time.
This is not congruent with the sentence from the documentation cited above.
So, let's preface this with the fact that time zones are hideous and infinitely confusing, I also haven't done anything with this for months/years.
I was going to try and think about explaining this, but that's probably less useful than me asking: what is it that lead you to ask this question or see this as a problem? What are you trying to achieve here?
Some code was updated to start using datetime.now(tz) and the corresponding test assertion added a tzinfo to the datetime output expectation.
However, no tzinfo was added to the test_datetime() constructor, so I wanted to:
- understand how/why this test was working
- ensure it would continue working across DST transitions in the local time of the host running the tests
- ensure it would continue working with future versions of
testfixtures(i.e. that we're not relying on a bug that is liable to be fixed in the future)
Couldn't parse "the corresponding test assertion added a tzinfo to the datetime output expectation.", can you provide an example?
-
"understand how/why this test was working": best bet is to read the code.
-
"ensure it would continue working across DST transitions in the local time of the host running the tests": most reliable way to do this is to try and it a couple of machines in different timezones, and change their time briefly so you can check their behaviour in different DST conditions. At least in the UK, we have a DST transition coming up soon...
-
"ensure it would continue working with future versions of testfixtures": PRs to add tests "locking in" the current behaviour, if they're not already there, are always welcome. As would fixes to the docs such that they're clearer, although I'm mindful of the fact that docs relating to timezones can be clear for one person while being confusing for another, and vice versa once a change is made.
Timezones really are hateful.
I've had a crack at simplifying and clarifying the Timezones section in the associated PR.