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
2642	Timezone handling is incorrect: Uses GMT instead of localtime	psmith@…	Jacob	"Hi from sunny New Zealand.

I'm playing around at writting a blog system, and there seems to be some problems with the date and time handling.

Using plain old vanilla python on Freebsd, the time functions return correct values. e.g.

{{{
[smurf@black psc]# python
Python 2.4.1 (#2, Apr 24 2005, 12:02:35) 
[GCC 3.4.2 [FreeBSD] 20040728] on freebsd5
Type ""help"", ""copyright"", ""credits"" or ""license"" for more information.
>>> import os, datetime, time
>>> time.localtime()
(2006, 9, 2, 15, 42, 26, 5, 245, 0)
>>> time.gmtime()
(2006, 9, 2, 3, 42, 37, 5, 245, 0)
>>> 
}}}

In my settings.py the timezone is set to TIME_ZONE = 'Pacific/Auckland NZ'. But, alas, the time values produced under django are out, viz:

{{{
[smurf@black psc]# python manage.py shell
Python 2.4.1 (#2, Apr 24 2005, 12:02:35) 
[GCC 3.4.2 [FreeBSD] 20040728] on freebsd5
Type ""help"", ""copyright"", ""credits"" or ""license"" for more information.
(InteractiveConsole)
>>> import datetime, os, time
>>> time.localtime()
(2006, 9, 2, 3, 42, 57, 5, 245, 0)
>>> time.gmtime()
(2006, 9, 2, 3, 43, 16, 5, 245, 0)
}}}

Note the 12 hour differnce between the 15 and the 3. 

Okay that shouldn't be too much of a problem but when django updates the datebase (say by adding something through the admin interface) the date a time on the object is something like ""2006-09-02 15:24:00"". In otherwords the datebase is updated using the correct localtime.

And when django iterates over the objects using the generic views, because it uses the incorrect localtime;  it thinks that the objects date is 12 hours or so in the future and consequently doesn't include it (unless of course, I set allow_future to True, which I don't want to do).

"	defect	closed	Generic views	0.95	minor	duplicate	timezone		Unreviewed	0	0	0	0	0	0