Opened 17 years ago
Closed 12 years ago
#2626 closed Bug (fixed)
Datetime handling is broken when dealing with more than one time zone
Reported by: | Tom Tobin | Owned by: | Aymeric Augustin |
---|---|---|---|
Component: | Core (Other) | Version: | |
Severity: | Normal | Keywords: | |
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 |
Easy pickings: | no | UI/UX: | 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
.
In summary:
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.
Discussion thread:
http://groups.google.com/group/django-developers/browse_thread/thread/b8c885389374c040
Change History (34)
comment:1 Changed 17 years ago by
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 Changed 16 years ago by
Reporter: | changed from Tom Tobin <korpios@…> to Tom Tobin <korpios@…> |
---|
comment:3 Changed 16 years ago by
Owner: | changed from nobody to Brian Rosner |
---|---|
Status: | new → assigned |
comment:4 Changed 16 years ago by
Cc: | mike.scott@… added |
---|
comment:5 Changed 16 years ago by
Owner: | Brian Rosner deleted |
---|---|
Status: | assigned → new |
comment:6 Changed 16 years ago by
Owner: | set to nobody |
---|
comment:7 Changed 16 years ago by
Cc: | korpios@… added |
---|
comment:8 Changed 15 years ago by
Description: | modified (diff) |
---|
comment:9 Changed 15 years ago by
Description: | modified (diff) |
---|
comment:10 Changed 15 years ago by
milestone: | → 1.0 |
---|
comment:11 Changed 15 years ago by
milestone: | 1.0 → post-1.0 |
---|
Please don't change milestones just because you'd like to see something in 1.0.
comment:12 Changed 15 years ago by
Cc: | korpios@… removed |
---|
comment:14 Changed 15 years ago by
Reporter: | changed from Tom Tobin <korpios@…> to Tom Tobin |
---|
Removing my email from Reporter
in hopes that Trac stops emailing me.
comment:15 Changed 15 years ago by
Cc: | nreilly@… added |
---|
comment:16 Changed 15 years ago by
I only see the SQL element being discussed, however, there is a more general problem where even datetime.now() will (randomly?) report incorrectly.
Using Apache and both mod_python and wsgi I find that various uses of datetime.now() around a project will give another TZ.
comment:18 Changed 15 years ago by
#10587 was a dup; it has more details and a good proposed solution.
comment:19 Changed 15 years ago by
Cc: | George Song added |
---|
comment:20 Changed 15 years ago by
I want to make sure I have some basic decisions straight before tackling this problem. We want to only affect how datetime.datetime
objects behave, and not datetime.time
and datetime.date
objects, right? In other words, only models.DateTimeField
, not models.TimeField
and models.DateField
. I don't think timezone conversions are meaningful in those cases, at least not generally.
Also when I work on this problem, I will follow my proposal in #10587 unless there's any strong objections.
comment:22 Changed 14 years ago by
I'm deleting my earlier comment pointing to code at LaunchPad, since The Onion does not currently maintain any available open source code there (or anywhere, at the moment — we're very busy bees).
comment:23 Changed 14 years ago by
Cc: | miracle2k added |
---|
comment:24 Changed 14 years ago by
Cc: | jedie added |
---|---|
Owner: | changed from nobody to jedie |
Status: | new → assigned |
comment:25 Changed 14 years ago by
Cc: | Forest Bond added |
---|
comment:26 Changed 13 years ago by
Cc: | bronger@… added |
---|
Another very subtle problem arising from this is that conditinal view processing may break. If you read a last-modified model field from a PostgreSQL backend in your last_modified_func and return it, the resulting HTTP header field is incorrect if your timezone isn't GMT. The reason is that the decorator expects a datetime object with correct tzinfo, but the ORM doesn't set this field.
comment:27 Changed 13 years ago by
Cc: | Chris Chambers added |
---|
comment:28 Changed 13 years ago by
Owner: | changed from jedie to nobody |
---|---|
Status: | assigned → new |
comment:29 Changed 13 years ago by
Cc: | Dan Fairs added |
---|
comment:30 Changed 13 years ago by
#14253 is a related issue regarding the way admin handles timezones.
comment:31 Changed 13 years ago by
Cc: | cg@… added |
---|
comment:32 Changed 13 years ago by
Cc: | louis30 added |
---|
comment:33 Changed 12 years ago by
Severity: | normal → Normal |
---|---|
Type: | defect → Bug |
comment:34 Changed 12 years ago by
Easy pickings: | unset |
---|---|
Owner: | changed from nobody to Aymeric Augustin |
UI/UX: | unset |
comment:35 Changed 12 years ago by
Cc: | David Foster added |
---|
Go ahead, Tom - write us a patch! Check out #2447 which may be related.
I agree that the
os.environ['TZ']
is an ugly hack, there are other related tickets that back this up ;)