This should definitely be more known news, especially given that things like Django build their datetime localization functionality on the back of pytz. Guess I should probably look at migrating to datetuil… Aside, I didn’t know that dateutil did timezone work, I’ve mostly leveraged it in the past for its flexible date parsing.
I suppose I should apply for a hat for comments like this, but:
Switching Django to another time-zone library is a possibility, though it’d be a significant change and we’d have to handle it carefully. Our time-zone support is built in a way that, for a lot of common cases, avoids the need to work directly with the lower-level pytz code. Specifically:
Also, our timezone documentation tells you, if you have to manually convert a single datetime to a specific time zone, how to do it correctly. And the very next section there tells you not to try to work with localized datetime objects in code, but to let Django do conversions for you at input/output boundaries and work only with UTC in your application code.
This is much like Django’s Unicode support, where the framework does the messy work at the boundaries, rather than trying to teach every developer on earth how to do that correctly.
If you’ve got suggestions for how to do that more effectively, patches are welcome :)
Thanks for responding so thoroughly! Since I’m using Django REST, I wasn’t aware of Django does that with its forms. DRF seems to be able to, with its serializers, but requires slight modification. Perhaps that’s the problem with dealing with things at the boundaries, not everyone is going to use the same gatekeepers; I guess that’s the caveat with “common cases.”
For now I’ve been using a signal to ensure that certain models are in the timezone set with TIME_ZONE using the approach you linked to in the documentation, just to ensure that now matter what (de)serialization mechanism I use, I ensure things are in the correct timezone. My case however, is a little different, because I gotta sometimes convert first to a specified time zone and then translate to UTC.
Re patches, I think in effectiveness Django’s fine, but the problem here is correctness, given that pytz’s basis for timezone offsets can be as trustworthy as a hobbyist’s approximation. I looked at contributing to Django like a month ago, for changing pytz to dateutil, wouldn’t some sort of discussion be required before actual development?
The place to discuss such a proposal would be the django-developers mailing list; there’d be a lot to work out as far as how such a transition would happen, whether it’s worth doing, etc., and the mailing list is the place for that.