Changes between Initial Version and Version 8 of Ticket #2626
- Timestamp:
- Jun 25, 2008, 11:27:34 AM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #2626
- Property Triage Stage Unreviewed → Accepted
- Property Reporter changed from to
- Property Cc added
-
Ticket #2626 – Description
initial v8 1 Both at work and in my personal projects, I've found that things can get hairy in Django when dealing with multiple time zones. Datetimes are ''stored'' with the current time zone, but ''retrieved'' as naive datetime objects. This may be fine when working on a standard site publishing news within a single time zone, but constitutes broken behavior when working with more than one time zone. This also constitutes broken behavior when transitioning an existing site to a new time zone.1 Django doesn't handle multiple time zones well. 2 2 3 I propose that Django's datetime behavior be altered to store all datetimes in UTC, converting to the appropriate time zone as necessary. In most cases, users should be able to declare a local time zone and be done with it (and be able to transition cleanly to a new local time zone); in the instances where more complex datetime handling is necessary, users should be able to convert from UTC to an arbitrary datetime.3 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. 4 4 5 Towards the end of fulfilling the aims of this ticket, I furthermore propose that the [http://labix.org/python-dateutil dateutil] module be pulled into Django as an included submodule. (Dateutil is licensed under the Python license, so this shouldn't be an issue from a legal standpoint.) Dateutil implements wonderfully robust handling of time zones (among other things), including the ability to read the system time zone tables directly (whether on unix or Windows) and thereby avoiding the ugly `os.environ['TZ']` hack.5 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`. 6 6 7 I am willing to write the implementation of what this ticket proposes (if no one beats me to it); since this is fairly important for one of my personal projects, I'll likely see to it sometime this week. 7 In summary: 8 9 1) The PostgreSQL backends should ignore time zones completely. 10 11 2) An appropriate `Field`, rather than a backend, should handle time zone support. 12 13 Discussion thread: 14 15 http://groups.google.com/group/django-developers/browse_thread/thread/b8c885389374c040