Unit tests with freezegun when TIME_ZONE is not UTC

Using Django
1

I have an existing Django project (using Python 3.8) where TIME_ZONE = "Canada/Saskatchewan".

I’m writing some unit tests and want to check that an API is returning the correct “time created” value for an object.

I’m using freezegun to set the time but the resulting times are one minute out and I’m puzzled.

import datetime
import pytz
from freezegun import freeze_time
from django.test import TestCase

@freeze_time(
    datetime.datetime(
        2025, 7, 27, 0, 0, 0, tzinfo=pytz.timezone("Canada/Saskatchewan")
    )
)
class MyTestCase(TestCase):
    def test_time(self):
        print(datetime.datetime.now())

Running this test results in the output:

2025-07-27 06:59:00

When the time should be 07:00:00. Or maybe 06:00:00 (Sasketchwan is currently GMT-6)? I’m puzzled!

2

Some other odd results if I use different time zones:

“America/Los_Angeles”: 2025-07-27 07:53:00
“Europe/London”: 2025-07-27 00:01:00

I feel I must be too tired and forgetting something really dumb because this isn’t make any sense to me.

3

For what it’s worth I switched to using time-machine (v2.15.0) and zoneinfo, instead of freezegun and pytz, and things now work as expected:

import datetime
import time_machine
from backports.zoneinfo import ZoneInfo
from django.test import TestCase

@time_machine.travel(
    datetime.datetime(
        2025, 7, 27, 0, 0, 0, tzinfo=ZoneInfo("Canada/Saskatchewan")
    ),
    tick=False,
)
class MyTestCase(TestCase):
    def test_time(self):
        print(datetime.datetime.now())

Outputs:

2025-07-27 00:00:00
1 Like
4

I’ve been using freezegun consistently over the last years, its been working well, the only difference is that normally I write the time as iso8601 string instead of providing a datetime to it.

But this other package looks really nice as well.

Adam does such a great job for the community :slight_smile:

1 Like