Default timezone settings are different from the operating systems'

[berdario]

The settings.py template reads:

"On Unix systems, a value of None will cause Django to use the same timezone as the operating system."

but by leaving the TIME_ZONE off, it will use the TIME_ZONE defined in the global_settings... compared to explicitly overriding it with None: that instead will indeed use a django.utils.timezone.LocalTimezone instance

this is quite unexpected

moreover: the django.utils.timezone code warns that in case of problems, you'd be better off with pytz than by trying to use LocalTimezone

so, using None to automatically detect the system timezone as suggested, will prevent django from using pytz, even if it was installed

I don't know if it's fine to suggest that None could be used without warning about that, but in case I think it would be better to

• change the value in django/conf/global_settings.py to None

or

• change the comments inside django/conf/project_template/project_name/settings.py

[Aymeric Augustin]

None would be a more neutral value that 'America/Chicago' for TIME_ZONE, but changing that would be backwards incompatible -- the default dates back to before None was made a legal value. Also, it's one of these small bits of history that are part of Django's character... (granted, that's very subjective).

I think it's best to keep the comment short in the settings.py template and elaborate the various possibilities in the docs. I'm attaching a patch along these lines. I you think it addresses your concerns, could you change the "Triage Stage" to "Ready for Checkin"?

[Aymeric Augustin]

In [17809]:

Fixed #17733 -- Discouraged setting TIME_ZONE to None when USE_TZ is True. Thanks berdario for the report.

[Claude Paroz]

In [17818]:

[1.4.X] Fixed #17733 -- Discouraged setting TIME_ZONE to None when USE_TZ is True. Thanks berdario for the report.

Backport of r17809 from trunk.