Re: [PATCH] initdb: map Windows' new Canadian time zone names

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Tue, 20 Oct 2026 at 15:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> But the ones where the claimed UTC offset changes don't appear to me
>> to match up to anything.

> I didn't look at all, but did check Europe/Volgograd, and I'm not an
> expert at reading tzdata.zi, but doesn't the following mean they
> changed to UTC+3 in 2020?
> 4 - %z 2020 D 27 2s
> 3 - MSK
> If so, isn't Microsoft's "(UTC+03:00) Volgograd" correct here?

Yeah, I think you're right. Volgograd used to be UTC+3 with DST
in summer:

regression=# select '2010-01-01 00:00 UTC'::timestamptz at time zone 'Europe/Volgograd';
timezone
---------------------
2010-01-01 03:00:00
(1 row)

regression=# select '2010-06-01 00:00 UTC'::timestamptz at time zone 'Europe/Volgograd';
timezone
---------------------
2010-06-01 04:00:00
(1 row)

but now they're UTC+3 all year:

regression=# select '2026-01-01 00:00 UTC'::timestamptz at time zone 'Europe/Volgograd';
timezone
---------------------
2026-01-01 03:00:00
(1 row)

regression=# select '2026-06-01 00:00 UTC'::timestamptz at time zone 'Europe/Volgograd';
timezone
---------------------
2026-06-01 03:00:00
(1 row)

So CLDR's comment is wrong, and seemingly always has been if you
assume it's meant to specify the zone's standard time. But I don't
regard that as our bug to fix, especially since it's only a comment
so far as our code is concerned. Perhaps somebody more excited
about this than me will file a bug report with CLDR about these.

regards, tom lane