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

[Tom Tobin <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

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