1

I have been using django-time-zone for some time, but I am now experiencing a lot of problems with django 1.7

https://github.com/mfogel/django-timezone-field

I get the feeling that since Django doesn't have official support for a time zone field this is something I should handle with a char field and pytz.

Is this assumption true? Or should I continue to use django-time-zone?

Atma
  • 29,141
  • 56
  • 198
  • 299
  • I think your question would be clearer if you briefly explained the purpose of django-timezone-field; that is, to store a timezone itself as a field on a model (e.g. for storing a user's local timezone), as opposed to storing a timezone-aware datetime (for which the built-in `DateTimeField` should serve just fine.) This falls within the general question-asking advice of "start by explaining what problem you need to solve." – Carl Meyer Sep 15 '14 at 19:52
  • Also, this question is hard to usefully answer without knowing what sort of "problems in Django 1.7" you are experiencing. – Carl Meyer Sep 15 '14 at 19:54
  • @CarlMeyer I explained the answer here http://stackoverflow.com/questions/25854783/django-timezone-field-gets-error-unicode-object-has-no-attribute-zone – Atma Sep 16 '14 at 03:57

1 Answers1

1

There is nothing wrong with the concept of a dedicated Field class for storing a timezone in a model field, validating that the stored value is in fact a real timezone, and making the value available on the model as an actual pytz timezone instance (all of which django-timezone-field appears to do, based on its documentation). Seems pretty useful to me.

The fact that such a field is not built in to Django indicates only that it has never been in high enough demand to warrant adding to core Django. But there is a reason that the Field class is publicly documented as subclassable; it is intended that third-party packages like django-timezone-field should be able to provide useful field types that aren't in core.

So I would say that your assumption is false; you should not assume that simply because a certain specialized field type is not provided by Django itself, that it's a bad idea or should not be used. There are many high-quality and useful third-party field classes.

I can't speak to the implementation quality of django-timezone-field specifically, because I haven't used it or reviewed its code (though its documentation and test coverage speak well of it). And I can't speak to the specific issues you are encountering using it with Django 1.7, because you didn't explain what they are.

Carl Meyer
  • 122,012
  • 20
  • 106
  • 116