电子邮件“日期”标题应该是发件人的本地时间还是UTC？

Question

我正在用Python编写一个基于web的电子邮件客户端，出现了一个问题，电子邮件的“日期”标题应该在发送时表示在哪个时区。

RFC 2822在第3.3节中声明：

The date and time-of-day SHOULD express local time.

这在我看来似乎模棱两可；问题是谁的当地时间？电子邮件服务器还是发件人？当然，我会假设发件人（他可能在任何时区，并且可以在他们的帐户首选项中更改）。当我查看Python的email.utils.formatdate函数时，出现了进一步的混乱，该函数似乎只提供了两种选择：UTC或本地时间（服务器的）。对我来说，似乎没有任何指定备用时区的选项，还是我遗漏了什么？

使用time.mktime(senders_tz_aware_now_datetime.timetuple())将timeval传递给formatdate会产生一个UTC日期字符串，考虑到RFC上面所说的，这感觉是错误的。

那么“Date”应该是哪个时区，是否存在创建适当日期字符串的标准函数？

Answer 1

如果您想遵守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文档：

Optional localtime is a flag that when True, interprets timeval, and returns a date relative to the local timezone instead of UTC, properly taking daylight savings time into account. The default is False meaning UTC is used.

Answer 2

当google“email client local time”时，这是一个最重要的结果；不幸的是，这两个答案和附带的注释几乎没有涉及到python实现，并且无法完全与主题行对话（这就是google响应的来源）。

RFC是明确的，因为它很明显：“^Date:”头在编写时是本地的。邮件客户端通常写“^Date:”头（在我处理过的许多实现中的任何一个）。对于大多数（合理配置的）客户机，这将是客户机操作系统报告的本地时间。

在webmail的情况下，本地时间可以由用户代理提供（用户代理通常依次从OS获取本地时间）。更典型的是，它将由用户在web应用程序（la gmail）中设置。

重要的是，如果您“遵循RFC”（可能是网络协议的一个好主意），那么在接收客户端上的结果行为通常是显示发件人看到的邮件发送日期。这就是RFC中“应该”的全部内容。我不想在想同事发邮件的时间时看到UTC；我想知道他们的本地时间。这样，我可以在一个步骤中计算出时间差（他们的本地时间到我的本地时间），而不是两个步骤（他们的本地时间到UTC到我的本地时间）。我也能立即得到他们交流背景的线索（是晚上吗？工作时间？等等）。

Answer 3

只要使用UTC，你就会更快乐。

当规范使用像SHOULD这样的术语时，就会发生这种情况。我认为这两者都应该被禁止在规范中使用，因为它们总是产生不必要的复杂性。

使用UTC完全有效。