Converting Timezone-Naive Project to Timezone-Aware?

[Noemi]

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

[Jani Tiainen]

Hi,

Well first, have a staging database where you can test all your changes "risk free". It will allow you to do changes and determine best practices to upgrade your data. Since that is staging system, you can do it really risk free. Only risk is that you may lose some time but your production system is not affected at all.

Hopefully you do have QA team or at least good QA procedures to test your system before you can give a green light for your changes. Unit tests help in certain parts but they can't really tell that there aren't any bugs.

And there isn't really any shortcuts because only way to discover bugs is that something bad happens, you write a test to reproduce it and then fix it - there isn't really any way to tell if you have covered all potential issues with such a conversion before hand. It is guaranteed that you'll have some problems that you just happened to missed out. For example when doing math with dates DST changes may introduce interesting results.

And finally - you need to have a DRP - disaster recovery plan. So if things go really south you need to be prepared to handle it. 

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django...@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.

--

Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...