Comments (13)
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 eitherpytz.all_timezones
orpytz.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.
Related Issues (20)
- Support Django 4.2 HOT 2
- Django <= 3.X defaults to using ZoneInfoBackend instead of PYTZBackend HOT 2
- use_pytz=True doesn't seem to be default on django 3.2.21 HOT 1
- Django 5.0 support HOT 4
- Using the "Factory" timezone on systems that use the system zoneinfo database can cause problems HOT 1
- sorting list of timezones on ModelForm? HOT 1
- Great
- Does not support Django5 - This blocks upgrades HOT 6
- Requested setting USE_DEPRECATED_PYTZ, but settings are not configured. HOT 1
- How to convert timezone name to Coordinated Universal Time (UTC) HOT 1
- TimeZoneSerializerField should allow empty strings when required=False HOT 3
- Translate list items based on current locale HOT 1
- System timezones or installed tzdata may not cover pytz.common_timezones HOT 5
- `TimeZoneSerializerField` does not handle the empty string case HOT 2
- python3.10 support HOT 1
- Version 5.0 drops Django 3.1 support, but can be installed alongside it
- Help to fix 'Pacific/Fiji' timezone ValueError: Extraneous characters at end of TZ string HOT 1
- PYTZ 2022.2 Update Issues HOT 7
- KeyError: "choices" during migration after upgrading to 5.0 HOT 4
- Use `zoneinfo.available_timezones` instead of `pytz.common_timezones` converted to `ZoneInfo` HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from django-timezone-field.