Timezones. New in Django 1.4.

What and Why?

Under Django version 1.4 all dates stored and displayed for a single timezone. The one that is specified in project.settings.TIME_ZONE. Now you gain ability to store dates in UTC and render it with timezone correction.

Problems with localtime bypass is an additional plus. They can happen once a year. For e.g. 31 of November 2012 in Russia. Time from 2:00am to 3:00am in fact goes by twice. It may not be a problem for 99% of users. But it can become a nightmare for billing systems. So it's better to store time in UTC and display with user Time Zone correction. So "02:15am 31 November 2012" will become "2012-10-30T22:15:00+04:00" and "2010-10-30T23:15:00+03:00" that is so handy for programmers ;).

Concepts

datetime objects in Python support timezones with attribute tzinfo. If this attribute is filled out it is called "timezone-aware", otherwise it's "naive" date.
Django uses timezone-aware dates, if you've used new feature in Django 1.4 while update. (settings.USE_TZ=True)
"Default timezone" in Django is the one that is specified in settings.TIME_ZONE. (E.g. 'Europe/Kiev'). While "current timezone" is the one that activated this moment.

Current timezone

You need to know where is user from to show him his date and time. You can ask him directly and store his timezone in session BTW. You can use DB's like "maxmind", guessing his timezone by IP or even use JavaScript: Date.getTimezoneOffset(). One or another way we need to activate user's timezone to get access to rendering of timezone aware date and time in templates and forms.

Example of setting current timezone (from Django docs):

from django.utils import timezone

class TimezoneMiddleware(object):
    def process_request(self, request):
        tz = request.session.get('django_timezone')
        if tz:
            timezone.activate(tz)

Main functionality we need for this issue is concentrated in 'django.utils.timezone'.

Templates

Those dates workout is widely supported in templates along with Python code.

# Converting to Paris timezone
{% timezone "Europe/Paris" %}
    Paris time: {{ value }}
{% endtimezone %}

# default date display, like they're actually stored (UTC)
{% localtime off %}
    {{ value }}
{% endlocaltime %}

Migration

1. Setting settings.USE_TZ = True 
2. pip install pytz (read farther)
3. Convert DB datetime values into UTC time. (If it is different) 

Now your code supports timezones. You have to repair some old places where Django does not handle it for us. We have to convert naive dates into timezone-aware. Otherwise you can get wired bugs while changing Winter/Somer time. To complete the migration you have to use 'django.utils.timezone' and debug places where dates in new format are compared to "new" one's.

pytz

Library that handles handy timezone workout in python. Olson database and handy API are included for different timezone calculations. Despite it is optional in Django 1.4 developers recommend to include it. It helps Framework not to guess default timezones while calculating time and provides timezone list to render for users.

Conclusion

Those new features make me proud user of this framework and simplify many holes that I had to handle myself. E.g. with hosting app using Australia/Sydney Timezone and working with it in Europe/Kiev. ;)