Can't create migrations in Django 1.7 about django-timezone-field HOT 13 CLOSED

Any update with this? Can you paste your solution @beaumartinez, please?

from django-timezone-field.

Sorry for the delay @PragmaticMates. I forked the repo; my fix is in https://github.com/beaumartinez/django-timezone-field

from django-timezone-field.

As i was reading this you're reply popped up, thanks @beaumartinez - hero!

from django-timezone-field.

This causes me to now get the error in my time zone model fields: AttributeError: 'unicode' object has no attribute 'localize'

and

AttributeError: 'unicode' object has no attribute 'zone'

from django-timezone-field.

The problem is that in @beaumartinez's version he gets rid of the methods that change the string value in the DB into a DstTzInfo object for your use. Removing the pytz.timezone calls in CHOICES as in beau's fork but keeping the to_python etc methods seems to do the trick for me. https://github.com/azzy/django-timezone-field/

from django-timezone-field.

This worked for me:

def deconstruct(self):
    return 'pytz.timezone', (self.zone,), {}
type(pytz.UTC).deconstruct = deconstruct
pytz.tzinfo.BaseTzInfo.deconstruct = deconstruct

from django-timezone-field.

@valtron That works but you've just removed the ability to set a custom value for choices.

@azzy I agree with your evaluation of @beaumartinez 's solution

I see two ways this can be solved:

• change the choices argument to contain [<string>, <string>] rather than [<pytz.timezone>, <string>]. Django can serialize strings. I don't like this solution because the whole purpose of this field is to allow the rest of the app to interact with timezone objects, rather than strings. As detailed here https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.Field.choices the first argument of the choices field is what is exposed to the rest of the application.
• other way is a custom kwarg could be introduced, like allowed_timezones = [<string>, ...] This would default to either pytz.all_timezones or pytz.common_timezones. This would be backward incompatible.

Any other ideas? If you've got thoughts, let me know, cause I'm hoping to code this up tomorrow.

from django-timezone-field.

@mfogel I like the sound of making allowed_timezones a kwarg and making the pytz.timezone calls in the __init__, thereby making the choices kwarg unnecessary in the migrations (assuming that's what you mean/how this would work). How would this be backward incompatible if the kwarg is optional (esp. given that this is only a Django 1.7 issue)? I'm assuming it would be optional since you said it would default to pytz.all_timezones or pytz.common_timezones.

Also though I don't think that option A is so bad, considering that usually people don't interact with field.choices unless they're passing in choices (as far as I've seen anyway).

from django-timezone-field.

@mfogel choices can still be set to any list of deconstructibles. The code I posted monkey-patches pytz objects so that Django can handle them here. Am I missing something?

Either way, that code shouldn't be part of django-timezone-field. It was meant as a workaround only.

from django-timezone-field.

I've added commits to develop implementing support for deconstruction/migrations in the most sane way I can see.

I did alter the format of the choices kwarg to [<str>, <str>] (as you mention @azzy really isn't so bad) rather than introduce a new custom kwarg. I had to jump through some hoops to keep model validation working, but the test suite is passing so hopefully it's all well and good...

If you have time this week to try out what's on develop with django 1.7 and post any issues you have here, I'd appreciate it. I'm targeting a new release to pypi next weekend. Cheers.

from django-timezone-field.

Hey, mfogel. Just wanted to say your most recent commit fixed it for me with Django 1.7. Thanks!

from django-timezone-field.

Worked for me in 1.7, thanks @mfogel , looking forward to release on pypi.

from django-timezone-field.

Just pushed version 1.1 to pypi, which includes these fixes. Thanks for you guys' help, please file bugs as they come up.

from django-timezone-field.