Opened 6 years ago
Closed 6 years ago
#30288 closed Bug (duplicate)
PostgreSQL connections forced into UTC if setting.USE_TZ is True.
Reported by: | chris-bradley | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.11 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
DatabaseWrapper.ensure_timezone()
in django/db/backends/postgresql/base.py
forces the database to use self.timezone_name()
as its timezone. On the base class, timezone_name()
uses the following logic:
- Return
settings.TIME_ZONE
ifUSE_TZ
is not truthy. - Return
self.settings_dict['TIME_ZONE']
if it is set. - Return 'UTC' otherwise.
However, BaseDatabaseWrapper.check_settings()
prevents 'TIME_ZONE' from being set if the supports_timezones
feature is set on the backend. The database's timezone is thus always set to 'UTC' for databases such as PostgreSQL if USE_TZ
is set to True.
This creates problems if the database does anything involving the current date, which may be off by one from the Django's date. For instance, consider the following setup:
- Model
X
points at a view. X
has a field namedage_in_days
that points to a column defined asCURRENT_DATE - y
, wherey
is a date column.- The Django settings module has
USE_TZ
set toTrue
andTIME_ZONE
set to 'US/Eastern'.
X.age_in_days
will then be one too high if viewed between 7:00 PM (8:00 PM if DST is in effect.) and midnight.
A solution that would not break backwards compatibility is to allow 'TIME_ZONE' to be set on a databases settings dictionary even if supports_timezones
is set to True for the backend's features.
I have not checked if this is still an issue in later Django versions.
Duplicate of #23524. Feel free to read the relevant threads on django-developers and open a new one if you still believe the behavior should change.