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 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:

http://groups.google.com/group/django-developers/browse_thread/thread/b8c885389374c040

Change History (34)

comment:1 Changed 17 years ago by Chris Beaven

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 Changed 16 years ago by korpios

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

comment:3 Changed 16 years ago by Brian Rosner

Owner: changed from nobody to Brian Rosner
Status: newassigned

comment:4 Changed 16 years ago by Mike Scott

Cc: mike.scott@… added

comment:5 Changed 16 years ago by Brian Rosner

Owner: Brian Rosner deleted
Status: assignednew

comment:6 Changed 16 years ago by Brian Rosner

Owner: set to nobody

comment:7 Changed 16 years ago by korpios

Cc: korpios@… added

comment:8 Changed 15 years ago by korpios

Description: modified (diff)

comment:9 Changed 15 years ago by korpios

Description: modified (diff)

comment:10 Changed 15 years ago by anonymous

milestone: 1.0

comment:11 Changed 15 years ago by korpios

milestone: 1.0post-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 korpios

Cc: korpios@… removed

comment:14 Changed 15 years ago by korpios

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 anonymous

Cc: nreilly@… added

comment:16 Changed 15 years ago by Yeago

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:17 Changed 15 years ago by (none)

milestone: post-1.0

Milestone post-1.0 deleted

comment:18 Changed 15 years ago by Jacob

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

comment:19 Changed 15 years ago by George Song

Cc: George Song added

comment:20 Changed 15 years ago by George Song

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 korpios

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 miracle2k

Cc: miracle2k added

comment:24 Changed 14 years ago by jedie

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

comment:25 Changed 14 years ago by Forest Bond

Cc: Forest Bond added

comment:26 Changed 13 years ago by Torsten Bronger

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 Chris Chambers

Cc: Chris Chambers added

comment:28 Changed 13 years ago by jedie

Owner: changed from jedie to nobody
Status: assignednew

comment:29 Changed 13 years ago by Dan Fairs

Cc: Dan Fairs added

comment:30 Changed 13 years ago by Russell Keith-Magee

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

comment:31 Changed 13 years ago by cg@…

Cc: cg@… added

comment:32 Changed 13 years ago by louis30

Cc: louis30 added

comment:33 Changed 12 years ago by Łukasz Rekucki

Severity: normalNormal
Type: defectBug

comment:34 Changed 12 years ago by Aymeric Augustin

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

comment:35 Changed 12 years ago by David Foster

Cc: David Foster added

comment:36 Changed 12 years ago by Aymeric Augustin

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:
http://groups.google.com/group/django-developers/browse_thread/thread/cf0423bbb85b1bbf

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