On Feb 21, 10:57 am, Danny Adair <[email protected]> wrote: > The question was if TIME_ZONE is not UTC then whose "today" should it > be? And in that case I just find the user's "today" more logical than > the server's.
My point is that it should always be UTC. When you insert a date into the database, it will appear to be UTC: > select * from test_dates; 2012-02-21 > set time zone 'GMT-11'; > select * from test_dates where now() > datecol; 2012-02-21 > set time zone 'GMT+11'; > select * from test_dates where now() > datecol; (0 rows) Now, the connection time zone is always set to UTC (at least when using PostgreSQL) so it would be consistent to get the last edited date as UTC, too. The main point is this: when you store a date into the database you lose the information about in whose time zone the date was. You store the last_edit date as a date in Sydney time, but in the DB there is no information that it is in Sydney time. So, it is better to store it in UTC time to begin with. However there are no right answers here. It is better to avoid DateFields completely for last edited or poll closes type stuff when USE_TZ is True. If you are going to compare datetimes and dates, the correct answer depends on the user's time zone. In some cases you want the date in UTC time. Poll closes at one point in time, you don't want to have the poll open for some users because they happen to be in a "late" time zone. In some cases you want the date in local time zone (last edited date depends on user's time zone). That is why DateFields are in my opinion dangerous in USE_TZ setting. The documentation should warn about this. Of course, if you are using USE_TZ = True just to get internal handling in UTC, but you are only using just one time zone, then your viewpoint will be different. I am talking about true multi-timezone applications here. > > zone aware datetimes, they are handled as UTC datetimes in the Python > > process. I can't see any point why the time zone for the process > > should be something else? What is gained by that? Isn't using Europe/ > > Helsinki for the process timezone downright dangerous due to daylight > > saving times? Am I missing something obvious here? > > What is gained by that is that there's a default "activation" in case > you don't provide one of your own. > At least that's what I understood the interna to do (always work with > UTC, convert to localtime for output, default to TIME_ZONE) > If that's not the case, I agree, "working" with a local time is very > dangerous. > Nice example athttp://pytz.sourceforge.net/#problems-with-localtime I am not talking about the default time zone for users. I am talking about the default time zone of the Python process. What is stored in os.environ['TZ']. As you can have only a single value there (changing it in-flight is a no-no due to threading issues) I think the sanest choice is to have it as UTC. Sorry for the confusion about this. - Anssi -- 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?hl=en.
