1. 14
  1.  

  2. 4

    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.

    1. 6

      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:

      • When USE_TZ is True, we tell you to use django.utils.timezone.now() to get the current datetime or as a default for models to store (and what comes out of it – and what we store in your DB – is a UTC datetime).
      • When you set TIME_ZONE to tell Django your preferred default time zone, the forms system parses incoming datetime values as if they’re coming from that time zone (and uses pytz correctly when doing so).
      • When you set TIME_ZONE, the display helpers (like the localtime template filter, for example) will correctly use pytz to perform conversions for output.
      • You can temporarily change the request-local active time zone with the django.utils.timezone.activate() function, which lets you do things like per-user time-zone preferences, and will affect the form and display helpers.

      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 :)

      1. 2

        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?

        1. 1

          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.