2014-09-15 1 views
1

Я использую Джанго-временную зону на некоторое время, но я сейчас переживает много проблем с Джанго 1,7ручка django часовой пояс с полем поля или поле django-time-zone?

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

Я получаю ощущение, что с Django не имеет официальной поддержки поле часового пояса - это то, что я должен обработать с помощью поля char и pytz.

Это предположение верно? Или я должен продолжать использовать django-time-zone?

+0

Я думаю, что ваш вопрос будет более ясным, если вы кратко объяснили цель django-timezone-field; то есть для хранения самого часового пояса в качестве поля на модели (например, для хранения локального часового пояса пользователя), в отличие от хранения времени и времени, поддерживаемого часовым поясом (для которого встроенный 'DateTimeField' должен служить просто отлично.) Это подпадает под общий вопрос - просите совета «начать с объяснения, какую проблему вам нужно решить». –

+0

Кроме того, этот вопрос трудно с пользой ответить, не зная, какие «проблемы в Django 1.7» вы испытываете. –

+0

@CarlMeyer хороший вопрос чувак. –

ответ

1

Нет ничего плохого в концепции выделенного класса Field для хранения часового пояса в поле модели, подтверждая, что хранимое значение фактически является реальным часовым поясом и делает доступным значение для модели как фактический часовой пояс pytz экземпляр (все, что, по-видимому, делает django-timezone-field на основе его документации). Мне кажется очень полезным.

Тот факт, что такое поле не встроено в Django, указывает только на то, что он никогда не был в достаточно высоком требовании, чтобы гарантировать добавление к основному Django. Но есть причина, что класс Field публично задокументирован как подклассы; предполагается, что сторонние пакеты, такие как django-timezone-field, должны быть в состоянии предоставить полезные типы полей, которые не являются ядром.

Поэтому я бы сказал, что ваше предположение неверно; вы не должны предполагать, что просто потому, что определенный тип поля не предоставлен самим Django, что это плохая идея или не следует использовать. Есть много высококачественных и полезных сторонних полевых классов.

Я не могу говорить о качестве реализации django-timezone-field специально, потому что я не использовал его или не пересмотрел его код (хотя его документация и покрытие теста хорошо говорят об этом). И я не могу говорить о конкретных проблемах, с которыми вы сталкиваетесь, используя его с Django 1.7, потому что вы не объяснили, что это такое.