id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
2626	Datetime handling is broken when dealing with more than one time zone	Tom Tobin <korpios@…>	nobody	"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 [http://labix.org/python-dateutil 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.
"	defect	new	Core (Other)		normal				Unreviewed	0	0	0	0