On 21 févr. 2012, at 10:49, Anssi Kääriäinen wrote: >>> I can't see any point why the time zone for the process >>> should be something else? What is gained by that? Isn't using Europe/ >>> Helsinki for the process timezone downright dangerous due to daylight >>> saving times? Am I missing something obvious here? >> >> What is gained by that is that there's a default "activation" in case >> you don't provide one of your own. >> At least that's what I understood the interna to do (always work with >> UTC, convert to localtime for output, default to TIME_ZONE) >> If that's not the case, I agree, "working" with a local time is very >> dangerous. >> Nice example athttp://pytz.sourceforge.net/#problems-with-localtime > > I am not talking about the default time zone for users. I am talking > about the default time zone of the Python process. What is stored in > os.environ['TZ']. As you can have only a single value there (changing > it in-flight is a no-no due to threading issues) I think the sanest > choice is to have it as UTC. Sorry for the confusion about this.
os.environ['TZ'] controls the ouptut of functions such as datetime.fromtimestamp(). If you're running with USE_TZ = True, you should use the UTC versions, e.g. datetime.utcfromtimestamp() in your own code. However, you may be relying on third party code that hasn't been adapted for time zone support yet. For such code to work properly, it's better to keep settings.TIME_ZONE == os.environ['TZ'] == your "main" time zone == what the user sees by default. Best regards, -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
