Hi Klaas, Le mardi 12 juin 2012 13:13:14 UTC+2, Klaas van Schelven a écrit : > > 1] Migration of non-UTC to UTC: is there any script / best practice > available? > Django's documentation mentions that all data should be converted to UTC > when switching to USE_TZ=True. See: > https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#other-databases > This is a rather concise remark. Are there any scripts/tricks available to > do this in "one go", and to be able to easily do the same conversion in > development and production. >
I assume it's possible to walk through all models and look for DateTimeFields, then perform the conversion. However performance must be taken into account — your database may not like large updates, and handling of special cases too. As you know, conversions from naive local time to UTC may fail (during the autumn DST transition). I haven't written that script and I don't know anyone else who has. No promises, but since you need it, I may find the motivation to write it. 2] The meaning of Queryset filtering: am I correct to understand that > operations on the DB are now always interpreted in UTC? > I.e. any direct comparisons to datetime? But also the __month __year > quasi-fields? > This does not appear to be documented explicitly anywhere, at least not in > the queryset documentation itself. > And should we not consider this a bug since a naive use of these is > explained in almost every single Django beginners toturial? > Yes, operations performed within the DB itself are in UTC, and as a consequence __day, __month, __year probably don't do what you expect when USE_TZ = True. The most recent state of my thoughts on this problem is here: https://code.djangoproject.com/ticket/17260#comment:14 > 3] Since date and datetime are radically different concepts (respectively > a point in time and a calendaring concept) what is the meaning of > auto_now and auto_now_add on a DateField? Is the current Timezone or the > default Timezone used? Should this not be documented? > The behavior hasn't changed, which means the default time zone is used. Specifically, the implementation calls `datetime.date.today()`, which relies on the process' time zone. Under Linux it's defined by the TZ environment variable, which is set to settings.TIME_ZONE. Under Windows I think it's always the system time zone. Generally speaking, the current implementation of auto_now and auto_now_add has some issues. For instance QuerySet.update() won't change the value of a field with auto_now=True. Therefore, I strongly recommend using `default=timezone.now` or a custom save() function, as it is more predictable. Best regards, -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/9PufMWWjvhwJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
