Обсуждение: BUG #18455: DST information is flagged wrongly

The following bug has been logged on the website:

Bug reference:      18455
Logged by:          gowtham kumar
Email address:      gkchinna.oracle@gmail.com
PostgreSQL version: 14.11
Operating system:   Linux
Description:

Hi Team,

Appears that for the timezone "Europe/Dublin" the is_dst is flagged
wrongly.

From the IANA data I can see "Europe/Dublin" is following the DST 

zdump -v /tmp/tzdb/zoneinfo/Europe/Dublin  | grep -i '2024'
/tmp/tzdb/zoneinfo/Europe/Dublin  Sun Mar 31 00:59:59 2024 UTC = Sun Mar 31
00:59:59 2024 GMT isdst=1
/tmp/tzdb/zoneinfo/Europe/Dublin  Sun Mar 31 01:00:00 2024 UTC = Sun Mar 31
02:00:00 2024 IST isdst=0
/tmp/tzdb/zoneinfo/Europe/Dublin  Sun Oct 27 00:59:59 2024 UTC = Sun Oct 27
01:59:59 2024 IST isdst=0
/tmp/tzdb/zoneinfo/Europe/Dublin  Sun Oct 27 01:00:00 2024 UTC = Sun Oct 27
01:00:00 2024 GMT isdst=1

However, from the pg_timezone_names it is flagged to false though it is
actually following the DST 


postgres=# select substr( version(), 1, 17);
      substr       
-------------------
 PostgreSQL 14.11 
(1 row)

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)

utc_offset and abbrev is reflecting the correct data and the timestamp as
well is giving output as expected.

Is the information from the is_dst flag can be treated as bug?

PG Bug reporting form <noreply@postgresql.org> 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

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

I wrote:
> 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.

Further to that ... on recent Fedora I get

$ zdump -v Europe/Dublin | grep 2024
Europe/Dublin  Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=1 gmtoff=0
Europe/Dublin  Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 IST isdst=0 gmtoff=3600
Europe/Dublin  Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 IST isdst=0 gmtoff=3600
Europe/Dublin  Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=1 gmtoff=0

So Red Hat is indeed moving in the direction of adopting the vanguard
data; they just haven't pulled that trigger yet in RHEL.

            regards, tom lane