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

Question

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

RFC 2822在3.3节中指出：

  

日期和时间应该以当地时间表示。

这对我来说似乎含糊不清;问题是当地时间是谁？电子邮件服务器或发件人？当然，我会假设发件人（可以在任何时区，并且可以更改其帐户首选项）。当我看到Python的email.utils.formatdate函数时，出现了进一步的混乱，这似乎只提供两种选择：UTC或本地时间（服务器的）。对我来说似乎没有任何指定备用时区的选项，或者我错过了什么？

使用time.mktime(senders_tz_aware_now_datetime.timetuple())将时间值传递给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文档：

  

可选的localtime是一个标志，当为True时，解释timeval，并返回相对于本地时区而不是UTC的日期，正确考虑夏令时。默认值为False，表示使用UTC。

Answer 2

只需使用UTC，您就会更开心。

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

使用UTC完全有效。

Answer 3

当谷歌搜索“电子邮件客户端当地时间”时，这是一个最佳结果;不幸的是，这两个答案和附带的评论几乎没有解决python的实现问题，并且完全无法与主题行说话（这正是谷歌的回应）。

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

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

重要的是，如果您“遵循RFC”（可能是网络协议的一个好主意），RECEIVING客户端上的结果行为通常是显示发件人看到的邮件发送日期。这是RFC中“SHOULD”的重点。在试图找出同事发送电子邮件的时间时，我不想看到UTC;我想要他们当地的时间。这样，我可以一步计算出时差（他们当地的时间），而不是两个（当地时间到当地时间的UTC）。我也可以立即得到关于他们沟通情况的线索（是晚上工作时间等等）。