Я использую django-time-zone в течение некоторого времени, но теперь у меня много проблем с django 1.7.
https://github.com/mfogel/django-timezone-field
У меня такое ощущение, что, поскольку Django не имеет официальной поддержки поля часового пояса, это то, что я должен обрабатывать с помощью поля char и pytz.
Верно ли это предположение? Или мне продолжать использовать django-time-zone?
Нет ничего плохого в концепции выделенного класса Field для хранения часового пояса в поле модели, проверки того, что сохраненное значение на самом деле является реальным часовым поясом, и предоставления значения в модели как фактического экземпляра часового пояса pytz (все что, по-видимому, делает поле django-timezone-field, основываясь на его документации). Кажется довольно полезным для меня.
Тот факт, что такое поле не встроено в Django, указывает лишь на то, что оно никогда не пользовалось достаточно высоким спросом, чтобы оправдать его добавление в ядро Django. Но есть причина, по которой класс Field публично задокументирован как подкласс; предполагается, что сторонние пакеты, такие как django-timezone-field, должны иметь возможность предоставлять полезные типы полей, которых нет в ядре.
Так что я бы сказал, что ваше предположение ложно; вы не должны предполагать, что просто потому, что Django не предоставляет определенный специализированный тип поля, это плохая идея или что ее не следует использовать. Существует множество качественных и полезных сторонних полевых классов.
Я не могу конкретно говорить о качестве реализации django-timezone-field, потому что я не использовал его и не просматривал его код (хотя его документация и покрытие тестами говорят об этом хорошо). И я не могу говорить о конкретных проблемах, с которыми вы сталкиваетесь при использовании Django 1.7, потому что вы не объяснили, в чем они заключаются.
DateTimeFieldдолжен работать очень хорошо.) Это подпадает под общий вопрос-совет начать с объяснения, какую проблему вам нужно решить. - person Carl Meyer schedule 15.09.2014