Programmer blog

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 date...

Sometimes you have the task to decorate django form fields. In our case it was need to add different widget to form field depending on field type. You can know your field type by refering to it's python class name, e.g.: field . __class__ . __name__ You will get wrong symbols error if you try to refer this python variable in templates directly. So you need a custom template tag to serve here. Decision was not to return variable for tag but to add context variable, cause I had need to perform exact actions on certain field types. So tag example: @register . simple_tag ( takes_context = True ) def set_this_field_type ( context , field ) : """     Adds to context given field type variable     variable named "this_field_type"     """ context [ "this_field_type" ] = field . field . __class__ . __name__ return '' Now you can add this variable to your if statements. E.g. usage: {% ...