【发布时间】:2010-10-07 22:01:40
【问题描述】:
【问题讨论】:
标签: postgresql timezone
【问题讨论】:
标签: postgresql timezone
我假设您在表t 中有一个名为ct 的列,其类型为TIMESTAMPTZ。然后你可以使用:
SELECT EXTRACT(TIMEZONE FROM ct) FROM t;
以秒为单位获取时区的偏移量。它从UTC/GMT 为您提供3600,这意味着GMT+1、CET 或其他。返回的值取决于您的 TIMEZONE 设置。
示例(我住在德国,实际时区为 GMT+1/CET):
test=# select '2008-01-01 12:00:00 GMT+5'::timestamptz;
timestamptz
------------------------
2008-01-01 18:00:00+01
test=# set timezone to 'gmt';
SET
test=# select '2008-01-01 12:00:00 GMT+5'::timestamptz;
timestamptz
------------------------
2008-01-01 17:00:00+00
如您所见,它始终在配置的时区输出任何内容。所以EXTRACT(TIMEZONE FROM ...) 的偏移量取决于你的TIMEZONE 设置。在INSERT 上给出的时区丢失了,因为它不值得保存。重要的是一切都是正确的,这不应该取决于TIMEZONE 设置。 PostgreSQL 在这方面做得很好。
【讨论】:
“PostgreSQL 在这方面做得很好。”
我真的很喜欢 PostgreSQL,但在这个特殊的特性上它做得不好。时区不仅偏移到 GMT。时区严格遵守暗示夏令时的政治规则。由于有很多时区具有相同的偏移量和不同的夏令时规则 - 当 PG 忘记原始时区时,它实际上会丢失信息。
我个人以“美国/纽约”的形式分别存储重要日期的原始时区。如果有人有更好的解决方案-欢迎。
【讨论】:
由于 timestampz 是在 ZULU/GMT 时间的瞬间记录的,它永远不会改变它的偏移量(因为它是参考),所以没有必要记录时区。您只需在过去、现在或未来将偏移量添加/减去 GEOPOLITICAL 时区偏移量。
您确实需要知道当时适用于过去和现在的时间所在位置的确切地理政治时区。
出于时间目的,这可能会带来更多问题。它应该仍然有效。想想日落。如果某个位置地球有日落@午夜 ZULU 时间(北半球冬季在大西洋或加拿大北部到阿拉斯加的某个地方),并且该时间假定为该位置的晚上 8 点(-4:00 偏移)当您将其记录在系统中并将其记录为“winter-date-in-future 8:00 PM”时,它将在数据库中记录为格林威治标准时间 24:00。
现在,地球上的那个位置在与地理相关的时间推算中竖起大拇指,并称其时区为“+11:55”。因此,对于他们来说,当英格兰的午夜(格林威治标准时间午夜)时,他们希望将其称为上午 11:55,这完全是他们的选择。当任何计算机想要显示该位置(即地缘政治时区)的未来日期时,即使太阳正在落山,它们也会将其称为上午 11:55。当然,这将是您计划的那一天 :-) 他们的问题。
【讨论】:
在 Postgres 中,即使您将日期时间值存储在 timestamp with time zone 数据类型中,原始输入时区也会丢失。
缺点:
假设我是否有人们在世界各地使用他们的 Facebook 应用程序的日期时间数据(以及时区信息)。现在我将这些值存储在 timestamp with time zone 数据类型中。随机一天,我想看看人们在早上与晚上相比使用他们的 FB 应用程序的频率如何,以及是否在不同国家/地区看到相同的趋势。
但是等等,我不再有时区信息。
坐在华盛顿特区,我可以看到美国东部标准时间上午 10 点,活动在全球范围内展开。
优势:
如果您正在比较两个具有相同时区时间戳的数据源,但其中一个存储为本地手表显示的内容,而另一个则通过将其转换为 UTC 来存储。在这里,您只需将时间戳存储在 timestamptz 数据类型中,并告诉它属于哪个时区,然后您就可以轻松地比较它们。
例如,
PST 时区的活动记录在2014-10-19 10:23:54。现在两个独立的数据源分别存储它。 Datasource1 存储为2004-10-19 10:23:54 PST,Datasource2 存储为2014-10-19 18:23:54 UTC。如果它们存储在 timestamptz 数据类型中,它将在您执行时显示相同的时间
SELECT datasource1.time, datasource2.time
【讨论】: