关于在postgresql中使用时区的策略

Jér*_*e R 5 postgresql timezone datetime timestamp

我需要在我的应用程序中使用多个时区.

基本上我的系统生成数据,来自地球上任何地方的客户都可以访问它.

由于我的数据有一个相关的时间戳,我想到了以下处理时区的策略.

在Postgres:

  • 使用::timestamptz我的时间戳的类型创建我的表.没有时区的时间戳不允许混合::timestamp,::timestamptz在我的情况下看起来像一颗定时炸弹.

  • 将我的PG服务器系统的时区设置为UTC.

  • 设置timezone='UTC'postgresql.conf(可能并不需要,如果系统的TZ是UTC,但我是一个有点偏执,它花了我什么).

  • 创建表时添加以下检查:

    CONSTRAINT timestamp_must_be_utc CHECK(date_part('timezone':: text,"my_timestamp_field")= 0 :: double precision)

  • 以UTC格式存储我的所有时间戳

在客户端(python + pytz)

  • 将客户的时区存储在他的个人资料中,例如 'America/Los Angeles'

  • 在查询数据时将时区信息发送到postgres,这样我就能获得类似的东西SELECT xxxx FROM yyyy WHERE my_ts >= '2012-11-27 19:13:00+01'::timestamptz,让Postgres转换为UTC.或者我可以使用pytz进行转换,但似乎Postgres会做得很好.

  • 根据客户的时区转换时间戳,以便我可以正确显示数据+时间戳.

总而言之,我计划在任何地方使用UTC来存储和查询数据,并在显示数据时只使用时区转换.

我对Postgres及其处理时区的方式没有多少经验.我知道处理不同时区的日期和时间是多么困难(一旦你必须使用航班时刻表,你就会学到使用UTC是唯一可行的日期和时间微积分的方法)这就是我要问的原因这个问题让我更有经验的postgres用户可以确认或纠正我的策略.

有趣的链接:

Ric*_*ton 7

根据喜好自己做一杯茶/咖啡,预留一个小时左右,并阅读手册关于时间戳处理的详细信息.玩一下,一切都会变得清晰.

如果您使用"带时区的时间戳"(timestamptz),处理不同的时区是没有问题的.它应该被命名为"绝对时间戳",内部 UTC.时区部分未存储,它只是用于获得绝对时间.

因此 - 确保所有时间戳都包含更新时的相关时区,然后恰当地设置您的客户端时区.它们将在客户的时区返回给您,无论它们提供的时区如何.

它确实变得狡猾的是处理一天不总是24小时(有时一小时不是3600秒)的事实,并且DST根据国家和历史在不同的日期发生.那不是PostgreSQL,那只是现实世界.

  • <rant> DST是人类历史上最深刻的愚蠢思想之一.它既没有拯救任何日光(显然),也没有任何好处 - 只是混乱和骚扰.</ rant> (2认同)
  • 好消息!当我是世界皇帝(tm)时,我会解决这个问题.坏消息是,我让每个人都采用GMT(我住在格林威治附近),并调整地球的轨道以消除闰秒和闰年. (2认同)