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