For timestamp with time zone,the internally stored value is always in UTC (Universal Coordinated Time,traditionally known as Greenwich Mean Time,GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string,then it is assumed to be in the time zone indicated by the system’s TimeZone parameter,and is converted to UTC using the offset for the timezone zone.

对于某些人来说,在(1)所有内容都在同一时区或(2)应用程序层处理时区并仅将所有内容存储在某个时区(通常是UTC)的情况下,使用时区没有时区被认为是有效的.但它也被认为是反模式,简单,因为(1)的正确解决方案是将TimeZone设置配置为系统的给定一个时区,(2)已经解决,因为Postgresql已经将所有内容存储在同一时区(世界标准时间).

现在,随着这两个下来,我只有一个很好的理由使用时区没有时区.那时候你想要存储未来的事件,并且当我们到达那个时候必须触发某种警报.如果且仅当区域关于时区的法律规定的规则不会发生变化时,这可能适用于带时区的时间戳.最常见的变化规则是采用或不采用日光节约时间(DST).

例如,假设你在2013-06-15(尚未在夏令时)安排一些事件发生在2013-01-15 10:00(已经在夏令时),并且在2013- 06-15您的地区被指定采用DST;但是,在那之后的一段时间,政府改变了规则,并说你的地区将不再使用夏令时,突然你的预定时间变成2013-01-15 11:00(而不是10点),如果你使用时间戳与时区,并使您的TZ配置保持最新.当然,您可能还会注意到,如果您跟踪感兴趣的区域/时区中的规则更改,并且更新受影响的记录,也可以使用时区处理此类案例.

值得一提的是,一些地区确实经常改变这些规则(比如在巴西,有些州 – 而不是整个国家 – 经常会改变),但在大多数情况下它会更早地改变它,所以你的用户只会受到远离预定的事件的影响现在的时间.

尽管如此,我还有一个建议.如果您确实拥有不同时区的用户,日志或任何内容,请存储他们来自某个地方的时区,并选择并使用带时区的时间戳.通过这种方式,您可以(1)跨越彼此更接近的事件(不同于他们的时区)和(2)显示事件发生的原始时间(时钟时间).