Opened 12 years ago

Closed 11 years ago

#1149 closed defect (duplicate)

'now' outputs in UTC and UTC-offset wrong on Windows

Reported by: Michael@… Owned by: Adrian Holovaty
Component: Core (Other) Version:
Severity: normal Keywords: now utc time date zone Windows XP
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


When the 'now' tag is used in a template, the output is always in UTC and the 'TIME_ZONE' setting appears to be used incorrectly. This behavior has been observed on Windows XP Pro (I have not tried it on other platforms).

Example #1: TIME_ZONE = 'America/Chicago'
  template:    {% now "O Y-M-d H:i" %}
  Windows Control Panel -> Date/Time -> Time Zone: US Central

Result: +0000 2005-Dec-31 16:40

This result is exactly 6 hours ahead of the current local time.

Example #2 (same as above but with the following change: TIME_ZONE = ''

Result: +1800 2005-Dec-31 10:41

This result is the correct local time but the UTC offset of +1800 is wrong.

Change History (7)

comment:1 Changed 12 years ago by Marek Kubica

Seems to me like a dublicate of ticket #1119, isn't it?

comment:2 Changed 12 years ago by anonymous

It seems that both the now tag and date filter are broken in templates, which is odd because django.utils.dateformat.format doesn't return bogus information (aside from it being '+1600' rather than '-800', and the expansion of 'PST'):

>>> from django.utils.dateformat import format
>>> from import entries
>>> pub_date = entries.get_list()[0].pub_date
>>> pub_date
datetime.datetime(2006, 1, 7, 21, 53)
>>> format(pub_date, "h:i A T (O)")
'09:53 PM Pacific Standard Time (+1600)'


{{ entry.pub_date|date:"h:i A T (O)" }}

Outputs '09:53 PM Ame (+0000)'.

I assume that 'Ame' comes from "America/Los_Angeles", my TIME_ZONE.

comment:3 Changed 12 years ago by anonymous

Changing 'America/Los_Angeles' to 'PST8PDT' fixes this ('O' outputs +1600, 'T' outputs 'PST'), but only after the development server was killed and started again--for some reason the autoreload after saving doesn't update TIME_ZONE.

(Probably the cause of the strange behavior of format, above, as I was changing the TIME_ZONE settings but not manually restarting the server.)

comment:4 Changed 12 years ago by Marek Kubica

Yes, the development server does not read the TIME_ZONE settings on reload. I already filed this behavior as ticket #1120 some time ago.

comment:5 Changed 11 years ago by anonymous

Component: Template systemCore framework

Putting TIME_ZONE = in does not work for Windows 2000 because when trying to run the server, I get next error:

.python runserver
Traceback (most recent call last):

File "", line 11, in <module>


File "C:\python25\lib\site-packages\django\core\", line 1404, in execute_manager execute_from_command_line(action_mapping, argv)
File "C:\python25\lib\site-packages\django\core\", line 1307, in


from django.utils import translation

File "C:\python25\lib\site-packages\django\utils\translation\", lin

e 3, in <module>

if settings.USE_I18N:

File "C:\python25\lib\site-packages\django\conf\", line 27, in ge



File "C:\python25\lib\site-packages\django\conf\", line 54, in _imp


self._target = Settings(settings_module)

File "C:\python25\lib\site-packages\django\conf\", line 109, in i


os.environTZ? = self.TIME_ZONE

File "C:\python25/lib\", line 426, in setitem

putenv(key, item)

OSError: [Errno 2] No such file or directory

comment:6 Changed 11 years ago by anonymous

Putting TIME_ZONE = "" in does not work for Windows 2000 because when trying ......

comment:7 Changed 11 years ago by Chris Beaven

Resolution: duplicate
Status: newclosed

I think this is the same issue as #2315: as soon as os.environ['TZ'] = self.TIME_ZONE is set, Windows starts having a bit of a mental time disassociative disorder.

Note: See TracTickets for help on using tickets.
Back to Top