15

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

RFC 2822在第 3.3 节中指出：

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

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

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

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

4

3 回答 3

9

如果您想遵守 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。

于 2012-05-07T19:11:26.413 回答
3

只需使用 UTC，您就会更快乐。

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

使用 UTC 是完全有效的。

于 2012-05-07T18:46:35.873 回答
2

在谷歌搜索“电子邮件客户端本地时间”时，这是一个最佳结果；不幸的是，这两个答案和随附的评论几乎没有解决 python 实现，并且完全无法与主题行交谈（这是谷歌响应的内容）。

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

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

重要的是，如果您“遵循 RFC”（对于网络协议来说可能是一个好主意），RECEIVING 客户端上的结果行为通常会显示发件人看到的邮件发送日期。这就是 RFC 中“应该”的全部意义。在试图弄清楚同事什么时间发送电子邮件时，我不想看到 UTC；我想要他们的当地时间。这样，我可以一步计算出时差（他们的本地时间到我的时间），而不是两个（他们的本地时间到 UTC 到我的本地时间）。我还可以立即获得有关他们通信背景的线索（是晚上吗？工作时间？等）。

于 2016-01-20T22:22:16.653 回答