Manual settings and the user's environment
Malcolm Tredinnick
templates inside their own code, without using the ORM or views.
It initially started out because they were using the old
os.environ['DJANGO_SETTINGS_MODULE'] = '__main__'
hack and had discovered that the timezone was being changed on them
throughout. After I pointed out there is manual configuration now, they
rediscovered a bug that I had forgotten to file or fix (yeah, I suck. I
wasn't near a network when I noticed it): we don't set os.environ['TZ']
when you use manual settings. This is good for this client, since they
want it left alone, but it's technically a bug, since it means the two
config methods behave differently in an undocumented way.
Two possibilities:
(1) We add a 'no_environ' parameter to settings.configure(). It defaults
to True. When False, we do not put anything into the environment when
installing the settings (for now, that just means TIME_ZONE, but it may
be other things in the future, I don't know).
(2) We leave things exactly as they are now on the grounds that somebody
using the manual configuration, on the balance, probably already has
their environment configured nicely and we shouldn't start playing with
it under the covers. We need to fix the docs in this case.
Either of these options seems reasonable to me. Do people have a strong
preference one way or the other?
I am not advocating changing the behaviour when using Django as a
full-up framework. There, setting the timezone does make sense, since we
can get it right once in one place, rather than asking everybody to
understand how os.environ behaves.
This is only for the standalone case (whether that be standalone
templates, views, models or "other") when somebody is integrating a part
of Django into another system.
Regards,
Malcolm
Malcolm Tredinnick
> I was having a discussion today with a client who are using Django
> templates inside their own code, without using the ORM or views.
>
> It initially started out because they were using the old
>
> os.environ['DJANGO_SETTINGS_MODULE'] = '__main__'
>
> hack and had discovered that the timezone was being changed on them
> throughout. After I pointed out there is manual configuration now, they
> rediscovered a bug that I had forgotten to file or fix (yeah, I suck. I
> wasn't near a network when I noticed it): we don't set os.environ['TZ']
> when you use manual settings. This is good for this client, since they
> want it left alone, but it's technically a bug, since it means the two
> config methods behave differently in an undocumented way.
>
> Two possibilities:
>
> (1) We add a 'no_environ' parameter to settings.configure(). It defaults
> to True. When False, we do not put anything into the environment when
> installing the settings (for now, that just means TIME_ZONE, but it may
> be other things in the future, I don't know).
>
> (2) We leave things exactly as they are now on the grounds that somebody
> using the manual configuration, on the balance, probably already has
> their environment configured nicely and we shouldn't start playing with
> it under the covers. We need to fix the docs in this case.
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. :-( ).
Malcolm
Russell Keith-Magee
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. At the very least, Django should check if there is an existing TZ setting before overriding it.
Russ Magee %-)
Malcolm Tredinnick
>
>
> On 7/6/06, Malcolm Tredinnick <mal...@pointy-stick.com> 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
Russell Keith-Magee
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?
True. This is a very compelling argument for keeping things the way they are.
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.
This seems like a reasonable idea to me. It has always slightly bugged me that the default timezone is America/Chicago, and I have to modify it on every project. Yes, it is a trivial thing to set, but 'system clock/no specific timezone' would be a better default than 'Chicago' (for everyone except Adrian, that is :-).
> 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?
Probably not very often. But for the cases where it does exist, overwriting it could be a bit confusing. I suppose good documentation of the overwriting process would be just as effective.
Russ Magee %-)
Malcolm Tredinnick
> On 7/6/06, Malcolm Tredinnick <mal...@pointy-stick.com> wrote:
> 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.
>
> This seems like a reasonable idea to me. It has always slightly bugged
> me that the default timezone is America/Chicago, and I have to modify
> it on every project. Yes, it is a trivial thing to set, but 'system
> clock/no specific timezone' would be a better default than
> 'Chicago' (for everyone except Adrian, that is :-).
The argument in favour of this is gathering strength: I just tried to
work out #2315 and, essentially, we're playing with fire trying to set
TZ on Windows systems. At least giving those people the option of
setting TIME_ZONE = None so that we don't mess up their existing
settings would be nicer than our current slightly misguided attempts.
Malcolm