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 1s2Z2s-00463A-Cq for pgsql-bugs@arkaria.postgresql.org; Thu, 02 May 2024 16:12:30 +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 1s2Z2p-002Bh7-Dq for pgsql-bugs@arkaria.postgresql.org; Thu, 02 May 2024 16:12:28 +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 1s2Z2p-002Bgz-5i for pgsql-bugs@lists.postgresql.org; Thu, 02 May 2024 16:12:28 +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 1s2Z2m-001CEn-Ji for pgsql-bugs@lists.postgresql.org; Thu, 02 May 2024 16:12: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 442GCMec2235699; Thu, 2 May 2024 12:12:22 -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: <2219450.1714662503@sss.pgh.pa.us> References: <18455-1f7c5337666bbd1a@postgresql.org> <2219450.1714662503@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 02 May 2024 11:08:23 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2235697.1714666342.1@sss.pgh.pa.us> Date: Thu, 02 May 2024 12:12:22 -0400 Message-ID: <2235698.1714666342@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > 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. Ah ... having now refreshed my memory, the answer is that RHEL and Apple are distributing "rearguard" tzdata files, whereas ours are built with the main ("vanguard") data model. The relevant difference is that the main model has the Irish rules as being standard time in summer and negative 1 hour DST in winter. The "rearguard" data is for parsers that cannot cope with the idea of negative DST, so it has +1 DST in summer and a different base GMT offset. It's alleged that this summer-time-is-standard concept more nearly matches the way the Irish law is written; the tzdb commentary includes # (Note that the time in the Republic of Ireland since 1968 has been defined # in terms of standard time being GMT+1 with a period of winter time when it # is GMT, rather than standard time being GMT with a period of summer time # being GMT+1.) In short: so far as the upstream tzdb project is concerned, we're doing the right thing, and I feel no need to change it. If you want to match the behavior of some other software, point --with-system-tzdata at the same zoneinfo tree that that other software is using. regards, tom lane