Должен ли заголовок "Дата" в электронной почте указывать местное время отправителя или UTC?

Я пишу почтовый веб-клиент на Python, и возник вопрос о том, в каком часовом поясе должен быть представлен заголовок "Дата" электронного письма, как при отправке.

RFC 2822 утверждает в разделе 3.3, что:

Дата и время суток ДОЛЖНЫ выражаться по местному времени.

Это кажется мне двусмысленным; вопрос по местному времени кто? Почтовый сервер или отправитель? Естественно, я предполагаю отправителя (который может находиться в любом часовом поясе и может быть изменен в настройках их учетной записи). Дальнейшая путаница возникла, когда я посмотрел функцию Python по адресу email.utils.formatdate, которая, кажется, предлагает только две альтернативы: UTC или местное время (сервера). Мне кажется, нет никакой возможности указать альтернативный часовой пояс, или я что-то упустил?

Передача временного интервала для форматирования даты с использованием time.mktime(senders_tz_aware_now_datetime.timetuple()) в результате получается строка даты в формате UTC, которая кажется неправильной, учитывая то, что RFC говорит выше.

Итак, какой часовой пояс должен быть "Дата", и существует ли какая-либо стандартная функция для создания соответствующей строки даты?

3 ответа

Если вы хотите придерживаться RFC, пройдите localtime=True который возвращает строку даты с местным временем и правильным часовым поясом (при условии, что он настроен правильно).

>>> email.utils.formatdate(localtime=True)
'Mon, 07 May 2012 12:09:16 -0700'

Без localtime=True Вы получаете строку даты, представляющую время UTC:

>>> email.utils.formatdate()
'Mon, 07 May 2012 19:08:55 -0000'

-0000 по-видимому, указывает UTC, хотя RFC специально рекомендует использовать +0000, Не уверен, что это ошибка в email.utils.

Вот соответствующая документация по Python:

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

Просто используйте UTC, и вы будете счастливее.

Вот что происходит, когда спецификации используют такие термины, как СЛЕДУЕТ. Я думаю, что оба ДОЛЖНЫ быть исключены из спецификаций, потому что они всегда создают ненужную сложность.

Использование UTC совершенно правильно.

Это лучший результат при поиске "почтового клиента по местному времени"; К сожалению, два ответа и сопровождающие комментарии едва касаются реализации Python и не могут полностью рассказать о теме (именно это и есть ответ Google).

RFC недвусмысленен, потому что он очевиден: заголовок "^Date: " является локальным на момент написания. Почтовый клиент обычно пишет заголовок "^Date: " (в любой из многих реализаций, с которыми я имел дело). Для большинства (разумно настроенных) клиентов это будет местное время, сообщаемое операционной системой клиента.

В случае веб-почты местное время может быть предоставлено пользовательским агентом (который обычно получает свое локальное время от ОС по очереди). Более типично это будет установлено пользователем в веб-приложении (как Gmail).

Важно отметить, что если вы "следуете RFC" (вероятно, это хорошая идея для сетевого протокола), то в результате на клиентах RECEIVING будет, как правило, отображаться дата отправки почты в том виде, в каком ее видел отправитель. В этом весь смысл "СЛЕДУЕТ" в RFC. Я не хочу видеть UTC, когда пытаюсь выяснить, во сколько коллега отправил электронное письмо; Я хочу их местное время. Таким образом, я могу определить разницу во времени за один шаг (их местное время по отношению к моему), а не по двум (их местное время до UTC и мое местное время). Я также получаю немедленные подсказки о контексте их общения (это была ночь? Рабочее время? И т. Д.).

Другие вопросы по тегам