mysql - 为什么 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 模型将这些对象插入 MySQL 后，它没有给出正确的结果 DateTimeField字段。

这是我的 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 ，我认为关键是理解“幼稚”和“有意识”值(value)观之间的区别。

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

然后我回头看了看你的问题。你说你在做以下事情:

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

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

If optional argument tz is None or not specified, the timestamp is converted to the platform’s local date and time, and the returned datetime object is 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 may be a DATE string, a DATETIME string, a TIMESTAMP, or a number in the format YYMMDD or 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 吗？功能？或者这就是您在测试中所做的？