On 7/6/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:

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 %-)


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to