Re: Time zone (Django 1.4) questions
Hi Aymeric, Thanks for the answers! I've decided to postpone the migration on one of our bigger projects to USE_TZ = True until after I have some experience with proper time zone handling in a greenfield project. This won't last forever, though, and once I get to it I'll report back with any globally-useful results. I imagine some of the answers to my questions will be worked into the docs at some point. If I can help out at that point in time I certainly will. ciao, Klaas On Jun 22, 10:57 am, Aymeric Augustin wrote: > Le jeudi 21 juin 2012 13:36:53 UTC+2, Aymeric Augustin a écrit : > > > > > 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. > > Here you go:https://gist.github.com/2971450 > > The script is designed to handle advanced cases (inherited models, proxy > models) but I haven't tested it. I've mentioned all the failure modes I > could imagine in the disclaimer. > > Let me know if it works for you! > > Best regards, > > -- > Aymeric. -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Time zone (Django 1.4) questions
Le jeudi 21 juin 2012 13:36:53 UTC+2, Aymeric Augustin a écrit : > > 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. > Here you go: https://gist.github.com/2971450 The script is designed to handle advanced cases (inherited models, proxy models) but I haven't tested it. I've mentioned all the failure modes I could imagine in the disclaimer. Let me know if it works for you! 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/-/NgCN-MDc_nEJ. 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.
Re: Time zone (Django 1.4) questions
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.
Time zone (Django 1.4) questions
Hi all, I have a number of questions on Django 1.4's Time Zones. 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. As asked here: http://stackoverflow.com/questions/10994101/django-1-4-use-tz-migration-database-part-best-practices 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? 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? Ciao! Klaas -- 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/-/En6oKxxs5FoJ. 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.
