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

[Tom Tobin]

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

[Chris Beaven]

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

[korpios]

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

[korpios]

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

[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.

[(none)]

Milestone post-1.0 deleted

[Jacob]

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

[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.

[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).

[Torsten Bronger]

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.

[Russell Keith-Magee]

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

[Aymeric Augustin]

More details here: ​http://groups.google.com/group/django-developers/browse_thread/thread/cf0423bbb85b1bbf

[Aymeric Augustin]

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