Code

Opened 8 years ago

Closed 3 years ago

#2626 closed Bug (fixed)

Datetime handling is broken when dealing with more than one time zone

Reported by: Tom Tobin Owned by: aaugustin
Component: Core (Other) Version:
Severity: Normal Keywords:
Cc: mike.scott@…, nreilly@…, gsong, miracle2k, jedie, forest, bronger@…, chrischambers, danfairs, cg@…, louis30, davidfstr 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

Attachments (0)

Change History (34)

comment:1 Changed 7 years ago by SmileyChris

  • Triage Stage changed from Unreviewed to Accepted

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

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

comment:3 Changed 7 years ago by brosner

  • Owner changed from nobody to brosner
  • Status changed from new to assigned

comment:4 Changed 7 years ago by micsco

  • Cc mike.scott@… added

comment:5 Changed 7 years ago by brosner

  • Owner brosner deleted
  • Status changed from assigned to new

comment:6 Changed 7 years ago by brosner

  • Owner set to nobody

comment:7 Changed 6 years ago by korpios

  • Cc korpios@… added

comment:8 Changed 6 years ago by korpios

  • Description modified (diff)

comment:9 Changed 6 years ago by korpios

  • Description modified (diff)

comment:10 Changed 6 years ago by anonymous

  • milestone set to 1.0

comment:11 Changed 6 years ago by korpios

  • milestone changed from 1.0 to post-1.0

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

comment:12 Changed 6 years ago by korpios

  • Cc korpios@… removed

comment:14 Changed 6 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 6 years ago by anonymous

  • Cc nreilly@… added

comment:16 Changed 6 years ago by subsume

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 5 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:18 Changed 5 years ago by jacob

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

comment:19 Changed 5 years ago by gsong

  • Cc gsong added

comment:20 Changed 5 years ago by gsong

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

  • Cc miracle2k added

comment:24 Changed 5 years ago by jedie

  • Cc jedie added
  • Owner changed from nobody to jedie
  • Status changed from new to assigned

comment:25 Changed 4 years ago by forest

  • Cc forest added

comment:26 Changed 4 years ago by 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 4 years ago by chrischambers

  • Cc chrischambers added

comment:28 Changed 4 years ago by jedie

  • Owner changed from jedie to nobody
  • Status changed from assigned to new

comment:29 Changed 4 years ago by danfairs

  • Cc danfairs added

comment:30 Changed 4 years ago by russellm

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

comment:31 Changed 3 years ago by cg@…

  • Cc cg@… added

comment:32 Changed 3 years ago by louis30

  • Cc louis30 added

comment:33 Changed 3 years ago by lrekucki

  • Severity changed from normal to Normal
  • Type changed from defect to Bug

comment:34 Changed 3 years ago by aaugustin

  • Easy pickings unset
  • Owner changed from nobody to aaugustin
  • UI/UX unset

comment:35 Changed 3 years ago by davidfstr

  • Cc davidfstr added

comment:36 Changed 3 years ago by aaugustin

  • Resolution set to fixed
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.