CHOICES does not contain the actual values stored in the DB about django-timezone-field HOT 5 CLOSED

By analogy with other complex fields, such as ForeignKeys, another approach is to have a hidden field <fieldname>_code that is just a CharField with simple choices, and then wrap that in a writable property <fieldname> where you can write and read pytz objects.

(For a ForeignKey the analogue is <fieldname>_id which is just an int and <fieldname> where you read and write model objects)

from django-timezone-field.

Thanks. If I change the choices field to

    CHOICES = [(tz, tz) for tz in pytz.all_timezones]

I get a whole bunch of test failures. So I'm a bit hesitant to make the change - I don't want to cause backward compatibility problems for people using the app. If you can construct a pull request that makes this change, and avoids likely backward compatibility issues... I'll entertain it.

from django-timezone-field.

This also causes problems with the new Django 1.7 migrations. Because timezone objects cannot be serialized, this makes migrations impossible.

Using the above new CHOICES code that uses a string value for both values in the tuple works.

An alternative solution that worked for me was to remove the choices attribute in the deconstruct method, but this is unideal and not a great workaround.

from django-timezone-field.

I'm hoping to get a chance to address this this weekend. Thanks guys.

from django-timezone-field.

I took the time to look deeper into this. The long and the short of this is - the docs were misleading. In general, the python representation of a field's value will not match the value stored in the database. The choices attribute of a field is expected to be of the form (python representation, human readable string). The database-level representation never comes into play here - how could it? It might be different on different DB platforms. The model field in intended to provide an abstraction such that other parts of the code don't have to (can't?) know about the database-level representation of the value.

I filed a ticket with django on clarifying the docs and adding a test to verify this is and stays the correct behavior. The patch has been accepted and merged in.

This doesn't address the django 1.7 incompatibility referenced here, which is certainly valid. But as there's several other tickets open about this now, I'm going to close this one and we can work through the django 1.7 issues on those other tickets.

from django-timezone-field.