Datetime handling is broken when dealing with more than one time zone
|Reported by:||Tom Tobin||Owned by:||Aymeric Augustin|
|Cc:||mike.scott@…, nreilly@…, George Song, miracle2k, jedie, Forest Bond, bronger@…, Chris Chambers, Dan Fairs, cg@…, louis30, David Foster||Triage Stage:||Accepted|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
Description (last modified by )
Django doesn't handle multiple time zones well.
Datetimes are potentially stored with a time zone offset based on
settings.TIME_ZONE (only for PostgreSQL), and retrieved as naive
datetime objects. This is fine when working on a standard site publishing items within a single time zone, but quickly becomes pathological when working with more than one time zone, or when transitioning an existing site to a new time zone.
I propose that Django's datetime handling be altered to ignore
settings.TIME_ZONE on all database backends, and let the appropriate Fields handle time zone conversion. I've already written a
DateTimeZoneField that appropriately handles multiple time zones and returns timezone-aware
datetime objects; for it to work consistently, however, the PostgreSQL backends need to stop using
TIMESTAMP WITH TIME ZONE and
SET TIME ZONE.
1) The PostgreSQL backends should ignore time zones completely.
2) An appropriate
Field, rather than a backend, should handle time zone support; such a field would require its backend storage to always be UTC, which can only happen cleanly if the backend ignores time zones.
Change History (34)
comment:2 Changed 9 years ago by
|Reporter:||changed from Tom Tobin <korpios@…> to Tom Tobin <korpios@…>|
comment:24 Changed 7 years ago by
|Owner:||changed from nobody to jedie|
|Status:||new → assigned|
comment:34 Changed 5 years ago by
|Owner:||changed from nobody to Aymeric Augustin|