So I guess your units tests run with the current date and don't test behavior with different dates. That's something which has the potential to hide quite a few date related bugs until it's too late.
What I like to do to avoid this situation is to use property-based testing to test that the code works for all dates in the desired time span. For Python I use hypothesis [1] in combination with freezegun [2] for that. Here is an example of how that could look like:
from datetime import datetime, timezone as tz
from freezegun import freeze_time
from hypothesis import given, strategies as st
def business_logic():
# TODO: Refactor before 2038!
if datetime.now(tz=tz.utc) > datetime(2038, 1, 19, 3, 14, 7, tzinfo=tz.utc):
raise Exception("This code is not working after UNIX time overflow")
...
@given(dt=st.datetimes(max_value=datetime(9999, 12, 31, 23, 59, 59), timezones=st.just(tz.utc)))
def test_business_logic(dt):
with freeze_time(dt):
business_logic()
test_business_logic()
It's just that the unit tests are built on the assumption that if you go forwards 24/48/72 hours, the time will be the same but N day(s) ahead. And that breaks down when you shift time zones.
>don't test behavior with different dates
It basically tests with different dates every time it's run.
What I like to do to avoid this situation is to use property-based testing to test that the code works for all dates in the desired time span. For Python I use hypothesis [1] in combination with freezegun [2] for that. Here is an example of how that could look like:
[1]: https://hypothesis.readthedocs.io/en/latest/[2]: https://github.com/spulec/freezegun