On Wed, Nov 25, 2009 at 7:10 PM, jedie <google.gro...@jensdiemer.de> wrote: > On 25 Nov., 00:36, Russell Keith-Magee <freakboy3...@gmail.com> wrote: >> Why would it be? A datetime field isn't necessarily stored in UTC. It >> uses datetime.now() because that will return the same time as >> settings.TIME_ZONE. > > To improve my understanding: What if the server changed and the time > zone is not the same? IMHO the user can choose: 1. leave the > settings.TIME_ZONE to the old value, so all old datetimes are right, > but new datetimes are wrong. Or 2. he can update settings.TIME_ZONE > and old datetimes would be wrong, but new are right. Isn't it?
If the server changes, then it's up to the admin to manage that change. Django *won't* make a change that will silently destroy the integrity of existing databases in the field just by updating code, which is *exactly* what changing to utcnow would do. Right now, there are *thousands* of Django installations in the field - including many of my own - that rely on the fact that auto_now uses datetime.now() and returns a time localized to TIME_ZONE. This behavior may be flawed, but it doesn't change the fact that this is the way it currently is. Storing datetimes in UTC may be a better default strategy, but that doesn't change the way it currently is. I am in complete agreement that Django should have better support for time zones. As Rob Hudson pointed out, there is a long-standing ticket requesting this (#2626). Changing the behavior of auto_now to return utcnow doesn't address the larger problem. >> On top of that, making this change would be a *huge* backwards >> incompatibility, as any existing uses of auto_now etc would break. > > Yes. But it's easy to add a settings and the admin can choose between > now or utcnow. The default settings should be set utcnow. No, on two counts. 1. Adding a setting to fix a problem doesn't fix a problem. It adds a new problem. 2. The existing value is datetime.now. *If* we were to add such a setting (and let me tell you right now - we aren't going to), the default value *must* be to use datetime.now - otherwise you don't get backwards compatibility by default. Yours, 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 django-develop...@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.
