Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s2Y2v-003wT3-G9 for pgsql-bugs@arkaria.postgresql.org; Thu, 02 May 2024 15:08:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s2Y2t-001k1A-2W for pgsql-bugs@arkaria.postgresql.org; Thu, 02 May 2024 15:08:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s2Y2s-001k12-QQ for pgsql-bugs@lists.postgresql.org; Thu, 02 May 2024 15:08:27 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s2Y2r-001BqC-BT for pgsql-bugs@lists.postgresql.org; Thu, 02 May 2024 15:08:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 442F8N8Z2219451; Thu, 2 May 2024 11:08:23 -0400 From: Tom Lane To: gkchinna.oracle@gmail.com cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18455: DST information is flagged wrongly In-reply-to: <18455-1f7c5337666bbd1a@postgresql.org> References: <18455-1f7c5337666bbd1a@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Thu, 02 May 2024 12:21:24 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2219449.1714662503.1@sss.pgh.pa.us> Date: Thu, 02 May 2024 11:08:23 -0400 Message-ID: <2219450.1714662503@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > postgres=# select * from pg_timezone_names where name ilike '%dublin%'; > name | abbrev | utc_offset | is_dst > ---------------+--------+------------+-------- > Europe/Dublin | IST | 01:00:00 | f > (1 row) Huh, that is very interesting. On my MacBook with a build using --with-system-tzdata=/usr/share/zoneinfo, I get: postgres=# select * from pg_timezone_names where name ilike '%dublin%'; name | abbrev | utc_offset | is_dst ---------------+--------+------------+-------- Europe/Dublin | IST | 01:00:00 | t (1 row) and the same on a RHEL box. However, if I build using PG's internal copy of the timezone database: regression=# select * from pg_timezone_names where name ilike '%dublin%'; name | abbrev | utc_offset | is_dst ---------------+--------+------------+-------- Europe/Dublin | IST | 01:00:00 | f (1 row) We're all on 2024a (and Europe/Dublin hasn't changed definition recently anyway), so what's going on there? I suspect this may be down to different options being used in the "zic" run that builds the zone data files, but haven't had time to look closer than that. regards, tom lane