Question

我最近将Django项目从1.3升级到1.5，以便开始使用时区处理。因为我是个白痴，我的Django时区被设置为“America / NewYork”，而不是使用UTC。 Turning Django's timezone support on automatically sets Postgres to UTC。现在我遇到了运行直接SQL查询的问题。我似乎无法使时区过滤正确。这就是我正在做的事情：

接受来自用户表单的时间戳字段
使用stamp.astimezone(timezone('UTC'))
使用django.db.connection的游标将其作为参数（start.strftime('%Y-%m-%d %H:%M:00%z')）传递给原始SQL查询

执行的查询（登录到控制台）看起来是正确的：

SELECT to_char(created, 'YYYY-MM-DD HH12:MIam'),
COALESCE(heat_flow_1, 0.0) / 1000.0, COALESCE(heat_flow_2, 0.0) / 1000.0,
COALESCE(heat_flow_3, 0.0) / 1000.0
FROM results_flattenedresponse
WHERE installation_id = '66'
AND created BETWEEN TIMESTAMPTZ '2013-04-26 13:00:00+0000' AND TIMESTAMPTZ '2013-04-26 16:00:00+0000'

如果我将其复制并粘贴到PGAdmin中，我会得到我正在寻找的东西，一组行从美国东部时间上午9点开始。但是，从django.db.connection的光标返回的数据集将所有日期推进4小时（EDT和UTC之间的差异）。其余数据实际上是正确的，但日期被视为UTC并被推送到用户的活动时区（即使我调用了deactivate）。我觉得我现在有很多不好的想法联系起来试图解决这个问题，所以我不确定哪些部分是好的想法，哪些是坏的。

编辑/更新

我一直在尝试其他一些事情并且仍然得到不好的结果，但只有当我直接查询数据库时。上面的步骤2和3中的内容似乎并不重要。我可以看到的一个快速修复实际上是在查询中设置时区，例如SET timezone='America/New_York';然后撤消它，但这对于数据完整性来说似乎是个坏主意。

另一个奇怪的一点：我已经将Django时区设置为UTC，但是当我下载本地副本并查看数据时，它仍然被标记为好像已设置为America / New_York。我不知道这是不是由于我的本地服务器上的设置，或者是否存在Django在插入第二个（非默认）数据库时数据未正确本地化的错误，尽管如果是我希望我的问题会消失。

Answer 1

由于服务器现在处于UTC时间，因此默认情况下创建的内容返回UTC，因此第一位需要

SELECT to_char(created AT TIME ZONE %s, 'YYYY-MM-DD HH12:MIam')

并传入您想要查看的时区。这不是世界上最好的方法，但它在这里适用于我，因为查询都在一个对象中运行，该对象具有相关的时区作为属性。

用Postgres处理Django时区

1 个答案: