Opened 18 years ago

Closed 13 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 korpios)

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:

Change History (34)

comment:1 by Chris Beaven, 17 years ago

Triage Stage: UnreviewedAccepted

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 ;)

comment:2 by korpios, 17 years ago

Reporter: changed from Tom Tobin <korpios@…> to Tom Tobin <korpios@…>

comment:3 by Brian Rosner, 17 years ago

Owner: changed from nobody to Brian Rosner
Status: newassigned

comment:4 by Mike Scott, 17 years ago

Cc: mike.scott@… added

comment:5 by Brian Rosner, 17 years ago

Owner: Brian Rosner removed
Status: assignednew

comment:6 by Brian Rosner, 17 years ago

Owner: set to nobody

comment:7 by korpios, 16 years ago

Cc: korpios@… added

comment:8 by korpios, 16 years ago

Description: modified (diff)

comment:9 by korpios, 16 years ago

Description: modified (diff)

comment:10 by anonymous, 16 years ago

milestone: 1.0

comment:11 by korpios, 16 years ago

milestone: 1.0post-1.0

Please don't change milestones just because you'd like to see something in 1.0.

comment:12 by korpios, 16 years ago

Cc: korpios@… removed

comment:14 by korpios, 16 years ago

Reporter: changed from Tom Tobin <korpios@…> to Tom Tobin

Removing my email from Reporter in hopes that Trac stops emailing me.

comment:15 by anonymous, 16 years ago

Cc: nreilly@… added

comment:16 by Yeago, 16 years ago

I only see the SQL element being discussed, however, there is a more general problem where even will (randomly?) report incorrectly.

Using Apache and both mod_python and wsgi I find that various uses of around a project will give another TZ.

comment:17 by (none), 15 years ago

milestone: post-1.0

Milestone post-1.0 deleted

comment:18 by Jacob, 15 years ago

#10587 was a dup; it has more details and a good proposed solution.

comment:19 by George Song, 15 years ago

Cc: George Song added

comment:20 by George Song, 15 years ago

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 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 by korpios, 15 years ago

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 by miracle2k, 15 years ago

Cc: miracle2k added

comment:24 by jedie, 15 years ago

Cc: jedie added
Owner: changed from nobody to jedie
Status: newassigned

comment:25 by Forest Bond, 14 years ago

Cc: Forest Bond added

comment:26 by Torsten Bronger, 14 years ago

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 by Chris Chambers, 14 years ago

Cc: Chris Chambers added

comment:28 by jedie, 14 years ago

Owner: changed from jedie to nobody
Status: assignednew

comment:29 by Dan Fairs, 14 years ago

Cc: Dan Fairs added

comment:30 by Russell Keith-Magee, 14 years ago

#14253 is a related issue regarding the way admin handles timezones.

comment:31 by cg@…, 13 years ago

Cc: cg@… added

comment:32 by louis30, 13 years ago

Cc: louis30 added

comment:33 by Łukasz Rekucki, 13 years ago

Severity: normalNormal
Type: defectBug

comment:34 by Aymeric Augustin, 13 years ago

Easy pickings: unset
Owner: changed from nobody to Aymeric Augustin
UI/UX: unset

comment:35 by David Foster, 13 years ago

Cc: David Foster added

comment:36 by Aymeric Augustin, 13 years ago

Resolution: fixed
Status: newclosed

In [17106]:

Added support for time zones. Thanks Luke Plant for the review. Fixed #2626.

For more information on this project, see this thread:

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