Thread: 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