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

Question

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

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

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

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

---

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

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

Answer 1

Обновление, январь 2013 : Django 1.4 теперь поддерживает часовой пояс !!

---

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

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

Я также настоятельно рекомендую вам заглянуть в pytz модуль , который делает работу с часовыми поясами менее болезненной. Для внешнего интерфейса я создал «средство выбора часового пояса», основанное на общих часовых поясах в pytz. У меня есть одно поле выбора для области, а другое для местоположения (например, США / Центральный отображается с двумя полями выбора). Это делает выбор часовых поясов немного более удобным, чем просмотр списка из 400+ вариантов выбора.

Answer 2

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

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

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

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

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

Answer 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 сможет сделать то же самое и т. Д. Надеюсь, это поможет.

Answer 4

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

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

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

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

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

Answer 5

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

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

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

Попробуйте!

Answer 6

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