Джанго Путаница с часовыми поясами; Постгрес и Апач

Question

Настройка: несколько сайтов в Django на одном наборе серверов, обслуживаемых одной и той же группой процессов Apache. Некоторые сайты восточной TZ; некоторые центральные. База данных PSQL работает на отдельном сервере.

Когда я начинал, я не особо задумывался о том, как различные сайты будут обрабатывать часовые пояса; Думаю, я видел настройку TIMEZONE в Django и просто подумал, что она «справится». Теперь я вижу трещины.

Первая проблема: часовой пояс, кажется, переворачивается между Восточным и Центральным. Насколько я понимаю, благодаря поиску на этом сайте, это происходит потому, что среда os для TZ настроена на процесс Apache, в зависимости от того, для какого сайта Django он обрабатывает запрос, и если этот процесс обрабатывает запрос для сайта на другом Т.З. часовой пояс неправильный. Я считаю, что решение, которое я нашел здесь, состояло в том, что сайты разных часовых поясов должны обслуживать разные группы процессов. Пожалуйста, исправьте, если ошиблись.

Вторая проблема: локально в Linux, я сделал ./manage.py runserver с одного из моих сайтов с центральным временем (я на востоке). Я создал ресурс, дата публикации которого правильно отображается в админской панели на один час позже. Если посмотреть на фактическую запись PostgresSQL, часовой пояс даты публикации по-прежнему указан как -04. Использует ли Postgres часовой пояс самого сервера / компьютера и игнорирует настройки TZ в Django? Таким образом, все записи, сохраненные на сервере Postgres по восточному времени, будут отображаться как -04 или -05 в зависимости от перехода на летнее время?

Если кто-то еще имел дело с чем-то вроде этого, совет приветствуется. Даже если я разделю процессы Apache для центральных сайтов таким образом, что их настройки TZ не пересекаются, у меня все еще остается проблема Postgres, с которой приходится иметь дело. И тогда мне любопытно; если отметка времени PSQL является центральной, а настройка TZ - восточной, скажем, поля даты и времени учитывают TZ? то есть, если вы выполняете datetime.datetime.now (), когда Django установлен в EST, и он возвращает 14:00, тогда у вас есть фильтр для контента по дате публикации, которая меньше этого результата, будет ли он учитывать TZ ищите контент, время публикации которого было 13:00 CST или раньше?

Answer 1

Вот некоторые подробности об обработке часовых поясов в Django и Postgres, но я настоятельно рекомендую иметь дело исключительно с UTC на бэкэнде и преобразовывать только в местный часовой пояс во внешнем интерфейсе при представлении метки времени UTC дляПользователь.В Python вы можете узнать текущее время в UTC через datetime.datetime.utcnow().Я даже поместил свои серверы в часовой пояс UTC, но в этом нет особой необходимости.

Несколько часовых поясов не работают в Django;см. этот билет .Объекты datetime в стандартной библиотеке Python наивны для часовых поясов, и вам нужна библиотека, подобная pytz, чтобы это исправить, но, насколько я знаю, Django по-прежнему возвращает наивные объекты datetime, а не объекты с поддержкой часовых поясов, которые можно создать с помощью pytz.

Postgres проверит несколько мест, чтобы определить часовой пояс, включая переменную среды TZ, но TZ должен находиться в среде процесса postgres:

PostgreSQL 8.5.3.Часовые пояса

Если часовой пояс не указан ни в файле postgresql.conf, ни в качестве переключателя командной строки postmaster, сервер пытается использовать значение переменной среды TZ в качестве часового пояса по умолчанию.Если TZ не определен или не является ни одним из имен часовых поясов, известных PostgreSQL, сервер пытается определить часовой пояс операционной системы по умолчанию, проверяя поведение функции библиотеки C localtime ().Часовой пояс по умолчанию выбран в качестве наиболее близкого совпадения среди известных часовых поясов PostgreSQL.