2👍
you’ve been mixing up naive datetime object while having USE_TZ = True. To create current time you need to use timezone.now() instead of datetime.now()
From pytz doc
The major problem we have to deal with is that certain datetimes may occur twice in a year. … This means that if you try and create a time in the ‘US/Eastern’ timezone using the standard datetime syntax, there is no way to specify if you meant before of after the end-of-daylight-savings-time transition.
…
The best and simplest solution is to stick with using UTC. The pytz package encourages using UTC for internal timezone representation by including a special UTC implementation based on the standard Python reference implementation in the Python documentation.
…
If you pass None as the is_dst flag to localize(), pytz will refuse to guess and raise exceptions if you try to build ambiguous or non-existent times.
From django docs
Interpretation of naive datetime objects
When USE_TZ is True, Django still accepts naive datetime objects, in order to preserve backwards-compatibility. When the database layer receives one, it attempts to make it aware by interpreting it in the default time zone and raises a warning.
Unfortunately, during DST transitions, some datetimes don’t exist or are ambiguous. In such situations, pytz raises an exception. Other tzinfo implementations, such as the local time zone used as a fallback when pytz isn’t installed, may raise an exception or return inaccurate results. That’s why you should always create aware datetime objects when time zone support is enabled.
In practice, this is rarely an issue. Django gives you aware datetime objects in the models and forms, and most often, new datetime objects are created from existing ones through timedelta arithmetic. The only datetime that’s often created in application code is the current time, and timezone.now() automatically does the right thing.