On Tue, Feb 21, 2012 at 21:00, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: >[...] > The real problem is, as said before, that whatever you do, last edited > date doesn't work in multi-timezone setting. Somebody is going to see > last edited "tomorrow" or seeing his last edit as "yesterday".
I agree, "last edited" as a date with auto_now=True is useless. Can you think of an example that's not? I haven't been able to yet. > I really, really think the date should be UTC date. That is what you > are going to do comparisons against in the DB. In other words, once > you put the date value into the DB, it will be in time zone UTC in > there when you compare it against any datetime value! That goes together with your comment below about the default timezone always being UTC. If I'm in Sydney and the server's TIME_ZONE is Helsinki, either choice will be converted. 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. But again, this is only a problem for an "auto_now" date which I can't think of a sensible use case for. > In addition, I will once more say that if settings.USE_TZ = True, then > the Python process default time zone should be UTC. When using time Sorry I more or less just joined the discussion - I assume you mean by that TIME_ZONE should not be configurable if USE_TZ is True, but rather be fixed to UTC. > 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 at http://pytz.sourceforge.net/#problems-with-localtime I would personally prefer if timezone was part of auth.User, activation built-in and always done, and TIME_ZONE always UTC. Aymeric's response was: "As long as Django doesn't have a schema alteration API, it's difficult to change the User model. There's also the question of how to store timezones in the database. If we implemented this feature, we'd have to bless a timezone implementation. pytz is pretty much the standard, and it's highly recommended, but it's possible to use another implementation of tzinfo classes if you desire." which makes sense to me. Cheers, Danny -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
