Django с настройкой часового пояса системы и индивидуальными часовыми поясами пользователя

Насколько хорошо Django обрабатывает случай разных часовых поясов для каждого пользователя? В идеале я хотел бы запустить сервер в часовом поясе UTC (например, в settings.py установить TIME_ZONE = "UTC" ), так что все данные были сохранены в базе данных в формате UTC. Такие вещи, как this, меня пугает, поэтому я предпочитаю UTC везде.

Но как трудно будет хранить часовой пояс для каждого пользователя и все еще использовать стандартные форматирование datetime datetime и оболочки модели. Должен ли я предвидеть необходимость писать код обработки даты во всем мире, чтобы преобразовать даты в часовой пояс пользователя и снова вернуться к UTC?

Я все еще переживаю учебник django, но я знаю, насколько боль может быть связана с часами пользователя в некоторых других средах, которые предполагают системный часовой пояс повсюду, поэтому я подумал, что теперь буду спрашивать.

Мое исследование на данный момент состояло в поиске документации django и только поиске одной ссылки для часовых поясов.

Дополнительно:

Есть несколько ошибок, отправленных в отношении обработки Django и часового пояса.
Babel имеет некоторый код для django, который, похоже, касается форматирования часового пояса в локалях.

Ответ 1

Обновление, январь 2013. Теперь у Django 1.4 есть поддержка часовых поясов!!

Старый ответ по историческим причинам:

Я сам буду работать над этой проблемой для своего приложения. Мой первый подход к этой проблеме состоял бы в том, чтобы пойти с разработчиком django core Malcom Tredinnick в этот пост django-пользователя. Вы захотите сохранить настройку часового пояса пользователя в своем профиле пользователя, возможно.

Я также настоятельно рекомендую вам заглянуть в pytz module, что делает работу с часовыми поясами менее болезненной. Для передней части я создал "сборщик часовых поясов", основанный на общих часовых поясах в pytz. У меня есть один поле выбора для области, а другое для местоположения (например, US/Central отображается с двумя полями выбора). Это делает выбор времени более удобным, чем прохождение через список из 400 вариантов.

Ответ 2

Не так сложно записывать код, поддерживающий часовой пояс, в django:

Я написал простое приложение django, которое помогает обрабатывать проблемы с часовыми поясами в проектах django: https://github.com/paluh/django-tz. Он основан на коде Brosner (django-timezone), но использует другой подход для решения проблемы - я думаю, что он реализует нечто похожее на ваши и предложения FernandoEscher.

Все значения datetime хранятся в базе данных в одном часовом поясе (в соответствии с настройкой TIME_ZONE), а преобразование в соответствующее значение (то есть пользовательский часовой пояс) выполняется в шаблонах и формах (есть виджет формы для полей datetimes, который содержит дополнительный субвиджет с часовым поясом). Каждое преобразование даты и времени является явным - без магии.

Кроме того, существует кеш потока, который позволяет упростить эти преобразования данных (реализация основана на механизмах перевода django i18n).

Если вы хотите запомнить часовой пояс пользователя, вы должны добавить поле часового пояса в модель профиля и написать простую промежуточную ссылку (следуйте примеру из doc).

Ответ 3

Django вообще не обрабатывает его, в основном потому, что Python тоже не работает. Python (Guido?) До сих пор решил не поддерживать часовые пояса, поскольку реальность мира " более политическая, чем рациональная, и нет никакого стандарта, подходящего для каждого приложение".

Лучшее решение для большинства - не беспокоиться об этом изначально и полагаться на то, что Django предоставляет по умолчанию в файле settings.py TIME_ZONE = 'America/Los_Angeles', чтобы впоследствии помочь.

Учитывая вашу ситуацию pytz - это путь (уже упоминалось). Вы можете установить его с помощью easy_install. Я рекомендую время конвертации на сервере в UTC на лету, когда их попросит клиент, а затем преобразует эти UTC в пользовательский локальный часовой пояс на клиенте (через Javascript в браузере или через ОС с iOS/Android).

Код сервера для преобразования времени, хранящегося в базе данных с часовым поясом America/Los_Angeles в UTC, выглядит следующим образом:

>>> # Get a datetime from the database somehow and store into "x"
>>> x = ...
>>>
>>> # Create an instance of the Los_Angeles timezone
>>> la_tz = pytz.timezone(settings.TIME_ZONE)
>>>
>>> # Attach timezone information to the datetime from the database
>>> x_localized = la_tz.localize(x)
>>>
>>> # Finally, convert the localized time to UTC
>>> x_utc = x_localized.astimezone(pytz.utc)

Если вы отправляете x_utc на веб-страницу, Javascript может преобразовать его в часовой пояс пользовательской операционной системы. Если вы отправите x_utc на iPhone, iOS может сделать то же самое и т.д. Я надеюсь, что это поможет.

Ответ 4

Не эксперт по Django, но у afaik Django нет магии, и я даже не могу представить себе такую магию, которая бы сработала.

Например: вы не всегда хотите сохранять время в UTC. Например, в приложении для календаря вы хотите сохранить дату и время в локальное время, когда происходит событие календаря. Какая разница между серверами и часовым поясом пользователей. Таким образом, наличие кода, который автоматически преобразует каждое выбранное время и время в часовой пояс серверов, будет очень плохим.

Итак, да, вам придется самому справиться с этим. Я бы рекомендовал хранить часовой пояс для всего и, конечно же, запустить сервер в UTC, и пусть все время, создаваемые приложением, используют UTC, а затем конвертируют их в часовой пояс пользователей при отображении. Это не сложно, просто надоело помнить. когда дело доходит до времени, которое вводится пользователем, оно зависит от приложения, если вы должны преобразовать его в UTC или нет. Я бы в качестве общей рекомендации не конвертировать в UTC, а сохранять в часовом поясе пользователей, с информацией о том, какой часовой пояс есть.

Да, часовые пояса - большая проблема. Я написал пару сообщений в блоге по раздражающей проблеме, например здесь: http://regebro.wordpress.com/2007/12/18/python-and-time-zones-fighting-the-beast/

В конце концов вам придется самостоятельно заботиться о проблемах с часовым поясом, потому что нет реального правильного ответа на большинство вопросов.

Ответ 5

Вы можете начать с рассмотрения django-timezones приложения. Он предоставляет ряд полей модели по часовой стрелке (и их соответствующих полей формы и некоторых декораторов), которые вы могли бы использовать, по крайней мере, для хранения разных значений часового пояса для каждого пользователя (если ничего другого).

Ответ 6

Глядя на приложение django-timezones, я обнаружил, что он не поддерживает СУБД MySQL, поскольку MySQL не хранит ссылку на часовой пояс внутри DateTimes.

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

Там я делаю то же самое, что и система перевода django, поэтому вы можете получить уникальное изменение часового пояса пользователя. Там вы должны найти класс Field и некоторые утилиты datetime, чтобы всегда получать данные, преобразованные в пользовательский часовой пояс. Поэтому каждый раз, когда вы делаете запрос и выполняете запрос, все будет проверяться временем.

Попробуйте!