我需要在应用程序中使用多个时区。
基本上，我的系统生成数据，来自地球上任何地方的客户都可以访问它
由于我的数据有一个相关的时间戳，我考虑了以下策略来处理时区。
在Postgres:
-
为我的时间戳创建具有
::timestamptz类型的表。没有时区的时间戳是不允许的，因为在我的情况下，混合::timestamp和::timestamptz看起来就像一颗定时炸弹。 -
将我的PG服务器系统的时区设置为`UTC。
-
在
postgresql.conf中设置timezone='UTC'(如果系统的TZ是UTC，可能不需要，但我有点偏执，这不会花我任何钱)。 -
在创建表时添加以下检查：
CONSTRAINT时间戳_must_be_utc CHECK(date_part("时区"：：text，"my_timestamp_field")=0：：双精度)
-
将我的所有时间戳存储在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用户就可以确认或纠正我的策略。
有趣的链接：
- https://stackoverflow.com/a/9576170/1121179
- https://stackoverflow.com/a/10462428/1121179
根据喜好给自己沏茶/咖啡，留出一个小时左右的时间，阅读手册中关于时间戳处理的详细信息。玩一玩，一切都会清楚的。
如果使用"带时区的时间戳"(timestamptz)，那么处理不同的时区是没有问题的。它实际上应该被命名为"绝对时间戳"，内部是UTC。时区部分没有存储，它只是用来获取绝对时间。
因此，请确保您的所有时间戳都包含更新时的相关时区，然后适当地设置您的客户端时区。无论在哪个时区提供，它们都将在客户的时区返回给您。
它真正棘手的地方是处理这样一个事实，即一天并不总是24小时(有时一小时也不是3600秒)，夏令时根据国家和历史的不同而在不同的日期发生。那不是PostgreSQL，那只是真实的世界。