Hi folks -- We have an existing project with dozens of DateTimeFields and hundreds of millions of database records. It's an old codebase and timezone-naive; but upcoming business needs require us to convert the project to be timezone-aware.
Not only is this a big change, but it's a risky one, with tons of potential for data corruption and bugs. Last time we tried to introduce a single field recorded as UTC instead of local time, we were discovering and squashing subtle related bugs and even exceptions for 6 weeks afterwards (hurrah for legacy code). We've been increasing test coverage gradually over time, but we don't have heavy coverage of date/time conversions yet, and there are still substantial gaps in coverage overall; we don't have the manpower to fix that before we begin this initiative. Our preferred risk-mitigation approach would be to make the change incrementally (a few fields at a time) instead of all at once; but that doesn't seem possible, since USE_TZ is a globally-applicable setting. Has anyone made a change like this before, and can you recommend any tactics to de-risk the conversion? Thanks! Noemi -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/ed0ea6fb-17ba-4f46-9122-4c97f463ec6b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
