David Rowley <[email protected]> writes:
> On Tue, 20 Oct 2026 at 15:45, Tom Lane <[email protected]> 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
