Re: BUG #18455: DST information is flagged wrongly
От | Tom Lane |
---|---|
Тема | Re: BUG #18455: DST information is flagged wrongly |
Дата | |
Msg-id | 2219450.1714662503@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18455: DST information is flagged wrongly (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18455: DST information is flagged wrongly
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: