2015-09-26 3 views
2

Итак, в моих настройках у меня есть следующие:Как работает часовой пояс Django?

LANGUAGE_CODE = 'en-us' 

USE_I18N = True 

USE_L10N = True 

USE_TZ = True 

TIME_ZONE = 'Europe/Copenhagen' 

Однако, когда я выдаю:

timezone.now() 
datetime.datetime(2015, 9, 26, 8, 47, 15, 862729, tzinfo=<UTC>) 

И время на два часа позже.

Я читал документацию, и я мог видеть, что этот метод вызывает datetime.datetime(), и информация там правильная. Я мог видеть, что выход основан на переменной TIME_ZONE, которая настроена на мое текущее местоположение. Не должно ли timezone.now() получить правильное время TIME_ZONE?

Другой вопрос: получает ли datetime.datetime() информацию с сервера?

ответ

1
  1. Да, он получает информацию от машины, на которой выполняется код.
  2. Нет, это не дает вам местное время. Нет, он не использует часовой пояс из ваших настроек (doc ref, code ref). Он использует время UTC (Europe/Copenhagen - UTC + 2).
  3. Если вы хотите, чтобы получить локальный объект типа DateTime, вы должны сделать его наивным:

    timezone.make_naive(timezone.now(), timezone.get_current_timezone()) 
    
+0

Я добавил timezone.now для своих моделей.py, чтобы штамповать время модификации в некоторых классах. Разве нет лучшего способа? –

+1

Почему вы предлагаете использовать объект наивного datetime? Если 'USE_TZ = True', то' timezone.now(). Astimezone (timezone.get_current_timezone()) 'возвращает известный объект datetime в текущем часовом поясе. Хотя вам не нужно вызывать '.astimezone()' вручную; существует 'timezone.localtime()', который делает это для вас и соответствующего фильтра шаблонов ('localtime'), который вам также не нужно вызывать, если' USE_TZ = True' – jfs

+0

@ J.F. Себастьян, отличный момент! Спасибо :) –

2

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

Таким образом, работа Django заключается в том, что все известные даты хранятся в UTC. (Тем не менее, они могут или не могут быть возвращены из базы данных в формате UTC в зависимости от настройки базы данных.) Затем он предлагает вам инструменты (например, настройку TIME_ZONE и activate()), чтобы установить часовой пояс, который должен использоваться при визуализации шаблонов для пользовательского отображения ,

Итак, все, что вы описали по дизайну. Это на самом деле вызывает у вас проблему?

+0

Если я установил свой часовой пояс на settings.py и последним, я вызываю timezone.now(), не должен ли он возвращать правильное время? Как я уже упоминал, он возвращает объект времени два раньше. –

+0

@ E.Camilo: 8 утра в UTC и 10 утра в Европе/Копенгагене (с DST) * - это тот же самый момент времени *. Так что это правильное время. Параметр 'TIME_ZONE' сообщает Django о часовом поясе по умолчанию для пользовательского отображения, это не влияет на то, какой часовой пояс используется в объектах Python. Если вы действительно хотите его преобразовать, вы можете (см. # 2 [здесь] (https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#usage)), но это необычный прецедент. –

+0

Я подумал, что когда я устанавливаю часовой пояс на «Европа/Копенгаген», ссылка на часовой пояс будет автоматически установлена ​​на UTC + 2. Вот что меня смущает. –

Смежные вопросы