为什么Django时区设置会影响纪元时间？

Question

我有一个小型 Django 项目，可以将 MongoDB 中的数据转储导入 MySQL。在这些 Mongo 转储中是存储在纪元时间中的日期。无论时区如何，我都希望纪元时间相同，但我看到的是 Django TIME_ZONE 设置对 MySQL 中创建的数据有影响。

我一直在使用 MySQL UNIX_TIMESTAMP 函数测试我的数据库输出。如果我插入一个纪元为1371131402880（包括毫秒）的日期，我将我的时区设置为'America/New_York'，UNIX_TIMESTAMP 给我1371131402，这是相同的纪元时间，不包括毫秒。但是，如果我将时区设置为 'America/Chicago'，我会得到 1371127802。

这是我将纪元时间转换为 Python datetime 对象的代码，

from datetime import datetime
from django.utils.timezone import utc

secs = float(epochtime) / 1000.0
dt = datetime.fromtimestamp(secs)

我试图通过在 datetime 对象上放置一个明确的时区来解决此问题，

# epoch time is in UTC by default
dt = dt.replace(tzinfo=utc)

PythonFiddle for the code

我已经单独测试了这个 Python 代码，它给了我预期的结果。但是，通过 Django 模型 DateTimeField 字段将这些对象插入 MySQL 后，它并没有给出正确的结果。

这是我的 MySQL 查询，

SELECT id, `date`, UNIX_TIMESTAMP(`date`) FROM table

我通过将此查询结果中的 unix 时间戳列与 MongoDB JSON 转储进行比较来测试这一点，以查看时代是否匹配。

这里到底发生了什么？为什么时区会对纪元时间产生影响？

仅供参考，我使用的是 Django 1.5.1 和 MySQL-python 1.2.4。我还将 Django USE_TZ 标志设置为 true。

Answer 1

我不是 python 或 Django 大师，所以也许有人能比我回答得更好。但无论如何我都会猜测一下。

您说您将其存储在 Django DateTimeField 中，根据 the documents you referenced，将其存储为 Python datetime。

看the docs for datetime，我认为关键是理解“naive”和“aware”值的区别。

然后进一步研究，我遇到了this excellent reference。请务必阅读第二部分“朴素且有意识的日期时间对象”。这为 Django 控制了多少提供了一些背景信息。基本上，通过设置USE_TZ = true，您要求 Django 使用 aware 日期时间而不是 naive 日期时间。

然后我回头看了你的问题。您说您正在执行以下操作：

dt = datetime.fromtimestamp(secs)
dt = dt.replace(tzinfo=utc)

查看fromtimestamp函数文档，发现了这段文字：

如果可选参数tz为None或未指定，则timestamp转换为平台的本地日期和时间，返回的datetime对象是naive。

所以我认为你可以这样做：

dt = datetime.fromtimestamp(secs, tz=utc)

然后，在该函数的正下方，文档显示utcfromtimestamp 函数，所以它可能应该是：

dt = datetime.utcfromtimestamp(secs)

我对 python 的了解还不够，无法知道它们是否等效，但您可以尝试看看是否有区别。

希望其中之一会有所作为。如果没有，请告诉我。我非常熟悉 JavaScript 和 .Net 中的日期/时间，但我总是对这些细微差别如何在 Python 等其他平台中发挥不同的作用感兴趣。

更新

关于问题的 MySQL 部分，请查看this fiddle。

CREATE TABLE foo (`date` DATETIME);
INSERT INTO foo (`date`) VALUES (FROM_UNIXTIME(1371131402));

SET TIME_ZONE="+00:00";
select `date`, UNIX_TIMESTAMP(`date`) from foo;

SET TIME_ZONE="+01:00";
select `date`, UNIX_TIMESTAMP(`date`) from foo;

结果：

DATE                           UNIX_TIMESTAMP(`DATE`)
June, 13 2013 13:50:02+0000    1371131402
June, 13 2013 13:50:02+0000    1371127802

UNIX_TIMESTAMP 函数的行为似乎确实受到 MySQL TIME_ZONE 设置的影响。这并不奇怪，因为它在文档中。令人惊讶的是，无论设置如何，datetime 的字符串输出都具有相同的 UTC 值。

这就是我认为正在发生的事情。在UNIX_TIMESTAMP 函数的文档中，它说：

date 可以是DATE 字符串、DATETIME 字符串、TIMESTAMP 或格式为YYMMDD 或YYYYMMDD 的数字。

请注意，它并不是说它可以是DATETIME - 它说它可以是DATETIME 字符串。所以我认为实际值在传递给函数之前被隐式转换为字符串。

所以现在看看this updated fiddle 显式转换。

SET TIME_ZONE="+00:00";
select `date`, convert(`date`, char), UNIX_TIMESTAMP(convert(`date`, char)) from foo;

SET TIME_ZONE="+01:00";
select `date`, convert(`date`, char), UNIX_TIMESTAMP(convert(`date`, char)) from foo;

结果：

DATE                           CONVERT(`DATE`, CHAR)  UNIX_TIMESTAMP(CONVERT(`DATE`, CHAR))
June, 13 2013 13:50:02+0000    2013-06-13 13:50:02    1371131402
June, 13 2013 13:50:02+0000    2013-06-13 13:50:02    1371127802

您可以看到，当它转换为字符数据时，它会去除偏移量。因此，当然，现在当UNIX_TIMESTAMP 将此值作为输入时，它假设本地时区设置并因此获得不同的 UTC 时间戳是有意义的。

不确定这是否对您有帮助。您需要更深入地了解 Django 是如何调用 MySQL 进行读取和写入的。它真的使用UNIX_TIMESTAMP 函数吗？或者这正是你在测试中所做的？