-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert TimeZoneField string value to timezone object on assignment #102
Conversation
(Incidentally, there seems to be some sort of packaging problem with wrapt which was already breaking the builds.) |
Please rebase and fix git conflicts. |
Add a descriptor_class that deserializes a string TimeZoneField value to a timezone object (pytz timezone or zoneinfo depending on settings) when it is assigned. As a side effect, invalid (non-blank) timezone names are detected immediately (rather than at save/full_clean time), and will immediately raise a ValidationError. Closes #57
@cclauss rebased and updated for current code. Looks like the CI workflow approval expired sometime in the past seven months, so someone will need to re-enable it. |
Below, it says:
|
Yes, exactly. (I'm not a maintainer on this repo.) |
Me neither. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #102 +/- ##
==========================================
+ Coverage 98.08% 98.14% +0.06%
==========================================
Files 9 10 +1
Lines 209 216 +7
==========================================
+ Hits 205 212 +7
Misses 4 4 ☔ View full report in Codecov by Sentry. |
@mfogel thanks for (resurrecting and) maintaining this package! |
Add a descriptor_class that deserializes a string TimeZoneField value to a timezone object (pytz timezone or zoneinfo depending on settings) when it is assigned.
As a side effect, invalid (non-blank) timezone names are detected immediately (rather than at save/full_clean time), and will immediately raise a ValidationError.
Closes #57
[There are two commits in this PR. The first, simpler one works for Django 3.0+. The second carries support back to Django 2.2. But if you're dropping Django 2.2 support soon anyway (it exited extended support a year ago), there's no reason to add that extra complication.]