Opened 10 years ago

Closed 9 years ago

#23820 closed New feature (fixed)

Make it possible to override USE_TZ & TIME_ZONE on a per-database basis

Reported by: Aymeric Augustin Owned by: Aymeric Augustin
Component: Database layer (models, ORM) Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When integrating with a legacy database, datetimes are most often encoded in local time. This doesn't work well with projects where USE_TZ = True.

The configuration for each database backend should accept a TIME_ZONE option to enforce interpretation of datetimes stored in that database as naive values in that time zone.

Setting this option when USE_TZ = False could either be an error or perform a conversion to the global default TIME_ZONE. The latter may be too complicated to be worth the effort.

Change History (10)

comment:1 by Tim Graham, 10 years ago

Triage Stage: Unreviewed → Accepted

comment:2 by Aymeric Augustin, 10 years ago

At least for SQLite, this will require getting rid of the ​global converters as there is no way to register converters per connection.

I'll try to replace the converters, which are quite messy anyway, with an implementation of DateTimeField.from_db_value.

comment:3 by Aymeric Augustin, 10 years ago

DatabaseOperations.convert_datetimefield_value seems to be a better match for what I'm trying to achieve.

See e9103402c0fa873aea58a6a11dba510cd308cb84.

Last edited 10 years ago by Aymeric Augustin (previous) (diff)

comment:4 by Aymeric Augustin, 10 years ago

Owner: changed from nobody to Aymeric Augustin
Status: new → assigned

comment:5 by Aymeric Augustin, 10 years ago

This will required getting rid of the global converters and adapters for datetimes, because they're hardcoded to use UTC regardless of the database connection being used.

Proposal: ​https://groups.google.com/d/msg/django-developers/Ci_cs0KTagM/DchJIB8-vRsJ

comment:6 by Aymeric Augustin, 10 years ago

Has patch: set

PR: ​https://github.com/django/django/pull/4601

comment:7 by Tim Graham, 9 years ago

Triage Stage: Accepted → Ready for checkin

comment:8 by Aymeric Augustin <aymeric.augustin@…>, 9 years ago

In ec18657:

Removed global timezone-aware datetime converters.

Refs #23820.

comment:9 by Aymeric Augustin <aymeric.augustin@…>, 9 years ago

In d9521f6:

Removed global timezone-aware datetime adapters.

Refs #23820.

Fixed #19738.

Refs #17755. In order not to introduce a regression for raw queries,
parameters are passed through the connection.ops.value_to_db_* methods,
depending on their type.

comment:10 by Aymeric Augustin <aymeric.augustin@…>, 9 years ago

Resolution: → fixed
Status: assigned → closed

In ed83881:

Fixed #23820 -- Supported per-database time zone.

The primary use case is to interact with a third-party database (not
primarily managed by Django) that doesn't support time zones and where
datetimes are stored in local time when USE_TZ is True.

Configuring a PostgreSQL database with the TIME_ZONE option while USE_TZ
is False used to result in silent data corruption. Now this is an error.

Note: See TracTickets for help on using tickets.
Back to Top