Open sstock opened 8 months ago
Apart from not running the test in the proximity of DST change, a solution would be modify the test such as it either takes DST into account, or its assertions are not disturbed by its effects... 🤔
Call it bad timing, but this was the first time I had ever built timew and the test phase failed. I managed to hit the 1% of the year, 2 days now and 2 more approximately six months distant, with an issue :-).
Being unfamiliar with the tests and code I'm not currently in a good position to suggest a solution of which there are several:
Steps taken:
Expected all tests to pass, but one did not: test_totals_with_time_delta_larger_than_24_hours failed because the start time actual was one hour off the expected time.
The significant aspect here is daylight saving time ended less than 48 hours ago. The test uses two times, now and 48 hours prior to now. The input times both use UTC. However the output (expected) values use the local time zone (in my case US/Eastern). I expect if I wait approximately 18 more hours the test will pass (update: 24 hours later and the test now passes when using my local time zone).
Forcing my local time zone to UTC, or any other that didn't recently change DST (e.g. Europe/Prague), allows the test to pass:
Note: relates to #255.
Miscellaneous details: OS: Ubuntu 22.04.3 LTS Python: Python 3.10.12