我需要在我的应用程序中使用多个时区。
基本上我的系统会生成数据，而且来自地球上任何地方的客户都可以访问它。
由于我的数据有一个相关的时间戳，我想到了以下处理时区的策略。
在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用户可以确认或纠正我的策略。
有趣的链接：
答案 0 :(得分：7)
根据喜好为自己准备茶/咖啡，留出一个小时左右的时间，并在details处理时阅读手册timestamp。玩一下，一切都会变得清晰。
如果您使用“带时区的时间戳”（timestamptz），处理不同的时区是没有问题的。它应该被命名为“绝对时间戳”，内部是 UTC。时区部分没有存储，它只是用于获得绝对时间。
所以 - 确保所有时间戳都包含更新时的相关时区，然后恰当地设置您的客户端时区。它们将在客户的时区返回给您，无论它们提供的时区如何。
它真正得到的是处理这样一个事实：一天不总是24小时（有时一小时不是3600秒），并且DST根据国家和历史在不同的日期发生。那不是PostgreSQL，那只是现实世界。