On Thu, 2006-07-06 at 10:11 +0800, Russell Keith-Magee wrote: > > > On 7/6/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Anybody have thoughts about this? > > Thinking about it further, I am more and more inclined to go > with option > #2: don't mess with the environment when running Django > components > embedded in another application. But I may be insane (the > phrase has > certainly been used in my presence before. :-( ). > > Well... if the shoe fits... :-) > > Seriously - I'm inclined to agree with #2 as well. In a pure Django > app, we know what needs to be/doesn't need to be in the environment. > If you are using manual settings, all bets are off in that regard. > Document the need for TZ if manually configuring, and leave things the > way they are. > > Truth be told, I'm even uncomfortable with the way Django sets TZ when > settings are loaded. To me, TZ should be documented as an external > environment requirement, rather than being a Django setting that > affects the environment.
Sometimes I think you're right about this and then some days not so much. I'm not sure there's a perfect answer to this one (remote database servers and a couple of assumptions in the code about UTC are usually the times when I decide that timezones are evil). The drawback with not setting it is that it's a pain in the hindquarters to get it right in all circumstances on your own. You need to set it very early so that the whole app is in the same timezone. So "manage.py runserver" will be slightly different from a mod_python setup, etc. We already spend enough time helping with people with basic Apache configuration; many of us would get it right, but they aren't the ones who will be posting to the mailing lists. Do we need the extra inconvenience? One idea that was bounced around in my conversation with the client was that TIME_ZONE defaults to empty (or None, preferably) and if, not set, does not get inserted into the environment. Personally, I don't really care too much about this, since it's such a trivial thing to set. > At the very least, Django should check if there is an existing TZ > setting before overriding it. I really don't have strong feelings either way on this. I gather the reason we do the current thing is for things like shared hosting where you don't have control over the machine's timezone. How often are we going to have TZ set in the environment when running a full-up Django, though? Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
