Malcom, Thank you for the elaborate explanation. That fixed the problem, and I actually understood it ;)
Michael > -----Original Message----- > From: django-users@googlegroups.com [mailto:[EMAIL PROTECTED] > On Behalf Of Malcolm Tredinnick > Sent: Sunday, August 19, 2007 11:54 AM > To: django-users@googlegroups.com > Subject: Re: TIME_ZONE setting: How does it work? > > > On Sun, 2007-08-19 at 11:15 +0200, Michael Elsdoerfer wrote: > > I'm having some trouble with time zones on my production machine > (debian, > > apache prefork with mod_python). On Windows, everything works as > expected. > > I'm running the trunk from maybe two weeks ago. > > More accurately, on Windows, Django's timezone stuff does absolutely > nothing. Setting timezones on Windows requires code we don't have > (there's an open invitation for somebody to write the necessary code if > they need it), so we don't modify the environment at all. > > > Basically, I have TIME_ZONE = 'GMT+1', but while > datetime.datetime.today() > > in a vanilla python shell returns the correct date, the same in > manage.py > > shell does not (off by 3 hours). > > You've fallen into a common trap with POSIX timezone specifications, > which is what are being used here. > > The string "GMT+1" actually means (in POSIX terms) "my timezone is > called 'GMT' and it is one hour *west* of the Prime Meridian." The > format is parsed as "name + offset" where offset is negative for East > and positive for West -- it's the number of hours you add to localtime > to get UTC, instead of vice-versa. > > Based on your e-mail headers, it looks like you are in the Central > European timezone and, since it's summer time, one hour behind UTC (west > of the Prime Meridian) is three hours behind your current timezone, > which is what you are seeing. > > So, either use something like "CET-2" or use the more descriptive names. > These names used to be in the PostgreSQL documentation, but I just > noticed that they have been removed in the latest version. So check a > slightly older version of the PostgreSQL documentation (using a similar > link to that in settings.py above TIME_ZONE) for some examples. > > > While I try to figure this out, allow me a more general question. It > seems > > every time I change the time zone, the date that gets written to my > MySQL > > database changes. > > > > Frankly, what I would have expected is: The values stored in the backend > > remain the same, only when read are interpreted differently. Isn't that > how > > it *should* work? Although I am always confused by time zones, so maybe > I'm > > way off here. > > Django doesn't support datetime fields with timezones. Instead, it > writes the time to the database using the local time (as configured via > the TIME_ZONE setting). This isn't particularly optimal in a number of > cases, but reflects Django's historical usage where the server was only > serving one timezone and never changing, etc. I would expect that to be > fixed in some fashion in the future, because it's hardly uncommon to > have to store multiple time-zoned information (even the Lawrence guys > are discovering this, I gather). There are also problems with corrupting > the environment for other processes by setting the TZ environment > variable. > > Tom Tobin has opened a ticket in Trac, volunteering to take on this > effort. I am fully behind it in the broader sense (although he doesn't > seem to have proposed using timezone-aware database fields yet, which is > the best solution a lot of times). > > > What am I missing? > > Don't let your assumptions lead you around by the nose. :-) > > Cheers, > Malcolm > > -- > Honk if you love peace and quiet. > http://www.pointy-stick.com/blog/ > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
