PostgreSQL now（）和夏令时

我们在PostgreSQL 9.0.10中遇到了夏令时问题。在尝试使用OS时区文件结构时，我们将PostgreSQL的文件替换为指向OS时区文件的链接（并重命名原始文件）

$ls-l/usr/local/pgsql/share/timezone/Brazil
/usr/local/pgsql/share/timezone/Brazil->/usr/share/zoneinfo/Brazil/

查询数据库时，一切正常：

=> SELECT * FROM pg_timezone_names where name like '%Brazil%';
           name            | abbrev | utc_offset | is_dst
---------------------------+--------+------------+--------
 Brazil.original/DeNoronha | FNT    | -02:00:00  | f
 Brazil.original/East      | BRST   | -02:00:00  | t
 Brazil.original/West      | AMT    | -04:00:00  | f
 Brazil.original/Acre      | AMT    | -04:00:00  | f
 Brazil/DeNoronha          | -02    | -02:00:00  | f
 Brazil/East               | BRT    | -03:00:00  | f
 Brazil/West               | -04    | -04:00:00  | f
 Brazil/Acre               | -05    | -05:00:00  | f

=> show timezone;
  TimeZone
-------------
Brazil/East

如上所示，“巴西/东部”为-03，DST为假。但我们得到的是：

=> select now(), now() AT TIME ZONE 'Brazil/East';
              now              |          timezone
-------------------------------+----------------------------
2018-10-21 11:25:51.300744-02 | 2018-10-21 11:25:51.300744

我们希望看到的是“2018-10-21 10:25:51.300744-03”，而不是这个日期 "-02".

---

关于我们这里缺少的内容有什么想法吗？

在PostgreSQL安装中替换文件不是正确且受支持的处理方法，因此得到奇怪的结果也就不足为奇了

您应该重新生成PostgreSQL，并使用

——和系统tzdata

对其进行配置，如中所述

---

但是当然你不应该使用9.0版，它已经失去支持大约3年了。

如果你使用的是不受支持的Postgres版本，那么你为什么不至少使用最新的次要版本9.0.23呢？由于每个次要版本都会附带最新的TZ文件，可能2015年的版本已经包含了您想要的补丁（9.0.10是在2012年发布的，所以间隔三年）。我们有一个无法进行此升级的场景。DST日期的更改仅在2周前由巴西政府完成：“对于小版本，社区认为不升级比升级风险更大”您当前的版本缺少3年的错误修复-其中一些甚至可能导致数据损坏（但确实无法解决您的DST问题）是的。无论如何，谢谢你的建议。：）我们有一个无法升级的场景。那么，显然数据对您来说不是很重要。在这种情况下，您不必担心升级。到目前为止，这并不是我们无法升级的原因。但无论如何，谢谢你抽出时间！我的意思是，即使你不想升级，如果你想使用不同的时区文件，你也应该重建PostgreSQL。