IsoDateTimeFromToRangeFilterTests fail with DST

[bmwiedemann]

One test starts to fail 2019-03-10 08:00 UTC
This coincides with a US DST 2019-03-10 02:00 (-0600)
test works again after end of DST ~ 2019-11-04

======================================================================
FAIL: test_filtering (tests.test_filtering.IsoDateTimeFromToRangeFilterTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/abuild/rpmbuild/BUILD/django-filter-2.1.0/tests/test_filtering.py", line 1005, in test_filtering
    self.assertEqual(len(results.qs), 2)
AssertionError: 1 != 2

----------------------------------------------------------------------
Ran 487 tests in 0.981s

FAILED (failures=1, skipped=14, expected failures=3)

This bug was found while working on reproducible builds for openSUSE.

[carltongibson]

So is this a DST issue? Will it re-occur every year? (Can you propose a fix? 😉)

[bmwiedemann]

Yes, it is a DST issue and it re-occurs every year. I looked at the code, but since I'm not a python expert and relevant code is distributed across multiple files and classes, it was not easy to see where the problem comes from. Maybe pdb could show things...

[carltongibson]

OK, thanks for the report. I will have a play at some point.

[carltongibson]

OK, so this just showed up here: https://travis-ci.org/carltongibson/django-filter/builds/514228812
Happily take a PR. If not I'll look at it at DjangoCon Europe sprints.

[lbazan]

• /usr/bin/python3 runtests.py
  Creating test database for alias 'default'...
  System check identified no issues (0 silenced).
  .......sssssss...................................................................................................s..x...u....ss..x..x...................................................................................................................................................................................................................................s....................sss.........................................................................................................

---

Ran 489 tests in 1.354s

FAILED (skipped=14, expected failures=3, unexpected successes=1)
Destroying test database for alias 'default'...

• exit 0

[carltongibson]

We'll need to revisit this after #1463.

Look into rewriting the test using @adamchainz's time-machine project

[adamchainz]

I think you could just decorate the test with:

@time_machine.travel(dt.datetime(2019, 3, 10, 7))

or similar, and the test will always run outside of DST.

[carltongibson]

That’s what I’m looking for. 😄