Question

所以我在这里使用gpx文件。记下一个摘录：

<?xml version="1.0" encoding="UTF-8"?>
<!-- GPSTrack 2.2.1 — http://bafford.com/gpstrack -->
<gpx xmlns="http://www.topografix.com/GPX/1/1">
<trk>
<name><![CDATA[2016-03-31 10-17-54]]></name>
<trkseg>
<trkpt lat="38.704859" lon="-8.970304"><ele>13.050667</ele><time>2016-03-31T09:17:51Z</time><!-- hAcc=95.768176 vAcc=10.000000 --></trkpt>
<trkpt lat="38.704894" lon="-8.970324"><ele>13.050667</ele><time>2016-03-31T09:17:55Z</time><!-- hAcc=141.087476 vAcc=10.000000 --></trkpt>
<trkpt lat="38.704859" lon="-8.970304"><ele>13.050667</ele><time>2016-03-31T09:17:55Z</time><!-- hAcc=95.768176 vAcc=10.000000 --></trkpt>
<trkpt lat="38.704878" lon="-8.970343"><ele>13.150488</ele><time>2016-03-31T09:18:43Z</time><!-- hAcc=165.000000 vAcc=10.000000 --></trkpt>

查看文件名称？它给了我们10H17的时间。现在检查每个点的时间。它少了一个小时。

我仍然不知道时间在这里搞砸了。但这是问题的开始。

现在，我正在解析这些gpx文件，并将它们加载到PostgreSQL数据库中。更具体地说，这个表：

CREATE TABLE IF NOT EXISTS trips (
  trip_id SERIAL PRIMARY KEY,

  start_location TEXT REFERENCES locations(label),
  end_location TEXT REFERENCES locations(label),

  start_date TIMESTAMP WITHOUT TIME ZONE NOT NULL,
  end_date TIMESTAMP WITHOUT TIME ZONE NOT NULL,

  bounds geography(POLYGONZ, 4326) NOT NULL,
  points geography(LINESTRINGZ, 4326) NOT NULL,

  timestamps TIMESTAMP WITHOUT TIME ZONE[] NULL
);

即使在使用TIMESTAMP WITHOUT TIME ZONE时，点数也会被加载错误的小时（少一小时）。这仅在夏令时生效后的几天内发生。这里的要点是：有没有办法检查日期是否在DST时间，并且如果进行检查则增加一小时？

我检查了tm_isdst和datetime.dst()，但我仍然不理解。

Answer 1

如果知道 时区名称 ，则应设置此本地时间（假设'Europe / Vienna示例中的“”，您可以使用以下表达式将值标准化为正确的UTC时间（或任何其他时区）：

SELECT '2016-03-31T09:17:51Z'::timestamp AT TIME ZONE 'Europe/Vienna' AT TIME ZONE 'UTC'

结果：

timezone
--------------------
2016-03-31 07:17:51

是的，应用AT ZIME ZONE 两次。

由于您似乎在处理不同的时区，我会考虑在您的表格中使用timestamptz代替timestamp。

请务必使用时区名称，而不是缩写或简单时间偏移来获得DST的精确调整。
_{我讨厌“夏令时”的愚蠢概念 - 它永远不会挽救任何日光，但却浪费宝贵的时间让人们感到困惑。}

所有这些的详细解释：

GPX和PostgreSQL的夏令时

1 个答案: