1

我最近将一个 Django 项目从 1.3 升级到 1.5，以便开始使用时区处理。因为我是个白痴，所以我的 Django 时区设置为“美国/纽约”而不是使用 UTC。打开 Django 的时区支持会自动将 Postgres 设置为 UTC。现在我遇到了运行直接 SQL 查询的问题。我似乎无法正确过滤时区。这就是我正在做的事情：

  1. 接受来自用户表单的时间戳字段
  2. 在我看来，将其交换为 UTCstamp.astimezone(timezone('UTC'))
  3. start.strftime('%Y-%m-%d %H:%M:00%z')使用 django.db.connection 的游标在原始 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 将数据插入第二个（非默认）数据库时，它没有正确本地化数据，但如果那是如果我希望我的问题会消失。

4

1 回答 1

1

由于服务器现在是 UTC 时间，创建的默认返回为 UTC，所以第一位需要是

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

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

于 2013-05-01T14:49:54.083 回答