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

Настройка: несколько сайтов на Django на одном наборе серверов, обслуживаемых одной и той же группой процессов Apache. Некоторые участки являются Восточной ТЗ; некоторые из них центральные. База данных - это PSQL, работающий на отдельном сервере.

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

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

Вторая проблема: локально в Linux я запустил сервер запуска ./manage.py с одного из моих сайтов с центральным временем (я нахожусь в Восточном). Я создал актив, дата публикации которого корректно отображается как отставание на один час в админке. Глядя на фактическую запись 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 или раньше?


person KRH    schedule 25.03.2010    source источник


Ответы (1)


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

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

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

Постгрес SQL 8.5.3. Часовые пояса

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

person Luke Stebbing    schedule 30.03.2010