GPX 和 PostgreSQL 的夏令时答案

【问题标题】：Daylight savings time for GPX and PostgreSQLGPX 和 PostgreSQL 的夏令时
【发布时间】：2016-12-05 22:30:43
【问题描述】：

所以我在这里使用 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()，但还是不明白。

【问题讨论】：

标签： python xml postgresql time dst

【解决方案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。
_{我讨厌愚蠢的概念“夏令时” - 它从不保存任何日光，而是不断浪费人们被它弄糊涂的宝贵时间。}

所有这些的详细解释：

【讨论】：

好吧，虽然我同意你关于 DST 浪费我们时间的观点，但在夏天多晒一小时太阳确实很好哈哈。所以，关于我的问题，我理解了你的回答，我把我的桌子改成了TIMESTAMP WITH TIME ZONE。尽管日期是在同一国家/地区收集的，但此 DST 孔被视为时区。使用pgAdmin 工具，我现在看到我的表格显示了类似2016-03-31 09:17:51+01 的日期。这意味着当我查询日期并将其传递给我想要的任何函数时，它会认为它是 10:17，对吧？
@Shoplifter.Doe: As explained in the linked answer，timestamptz 的显示适应会话的时区设置。您始终可以再次使用AT TIME ZONE 构造来获取给定时区的显示。当您cast 到date 时，也会考虑当前时区设置。
是的，我明白了。会话的时区设置绰绰有余。 “夏令时并不是人类曾经提出的最聪明的想法之一。” - 对于编程问题，确实如此。对我来说，SELECT start_date::timestamp AT TIME ZONE 'UTC' from trips 表达式是最适合我的。就像链接答案中的“装弹枪”一样。在我的前端，我可以使用一些 JS 库轻松处理这些日期。我远不知道这些时区可能会很痛苦。谢谢你的课。