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

[Tom Tobin <korpios@…>]

Both at work and in my personal projects, I've found that things can get hairy in Django when dealing with multiple time zones. Datetimes are stored with the current time zone, but retrieved as naive datetime objects. This may be fine when working on a standard site publishing news within a single time zone, but constitutes broken behavior when working with more than one time zone. This also constitutes broken behavior when transitioning an existing site to a new time zone.

I propose that Django's datetime behavior be altered to store all datetimes in UTC, converting to the appropriate time zone as necessary. In most cases, users should be able to declare a local time zone and be done with it (and be able to transition cleanly to a new local time zone); in the instances where more complex datetime handling is necessary, users should be able to convert from UTC to an arbitrary datetime.

Towards the end of fulfilling the aims of this ticket, I furthermore propose that the ​dateutil module be pulled into Django as an included submodule. (Dateutil is licensed under the Python license, so this shouldn't be an issue from a legal standpoint.) Dateutil implements wonderfully robust handling of time zones (among other things), including the ability to read the system time zone tables directly (whether on unix or Windows) and thereby avoiding the ugly os.environ['TZ'] hack.

I am willing to write the implementation of what this ticket proposes (if no one beats me to it); since this is fairly important for one of my personal projects, I'll likely see to it sometime this week.