1👍
From the Django docs on the TIME_ZONE
option:
If the database backend doesn’t support time zones (e.g. SQLite, MySQL, Oracle), Django reads and writes datetimes in local time according to this option if it is set and in UTC if it isn’t.
- If Django manages the database and you don’t have a strong reason to do otherwise, you should leave this option unset.
…
So that explains the results from your development environment using SQLite.
PostgreSQL behaves differently in this regard. From the same docs:
If the database backend supports time zones (e.g. PostgreSQL), the
TIME_ZONE
option is very rarely needed. It can be changed at any time; the database takes care of converting datetimes to the desired time zone.…
So either way, you should probably set only USE_TZ = True
, but not set the TIME_ZONE
option. Only set the TIME_ZONE
option when connecting to a legacy database that stores its date/time values in local time. If you’re storing time in UTC, you should not use the TIME_ZONE
option.
Instead, use the timezone.activate
function, to set the user’s display time zone to a particular time zone.
Some of this is also explained in the Django docs on time zones.