Andrew Dunstan <and...@dunslane.net> writes: > On 9/30/21 2:36 PM, Andres Freund wrote: >> CI showed me a failure in 002_types.pl on windows. I only just now noticed >> that because the subscription tests aren't run by any of the vcregress.pl >> steps :(
> We have windows buildfarm animals running the subscription tests, e.g. > <https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=drongo&dt=2021-09-29%2019%3A08%3A23&stg=subscription-check> > and they do it by calling vcregress.pl. But are they running with the prevailing zone set to "Greenwich Standard Time"? I dug around to see exactly how we handle that, and was somewhat gobsmacked to find this mapping in findtimezone.c: /* (UTC+00:00) Monrovia, Reykjavik */ "Greenwich Standard Time", "Greenwich Daylight Time", "Africa/Casablanca" According to current tzdb, # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Africa/Casablanca -0:30:20 - LMT 1913 Oct 26 0:00 Morocco +00/+01 1984 Mar 16 1:00 - +01 1986 0:00 Morocco +00/+01 2018 Oct 28 3:00 1:00 Morocco +01/+00 Morocco has had weird changes-every-year DST rules since 2008, which'd go a long way towards explaining funny behavior with this zone, even without the "reverse DST" since 2018. And sure enough, 002_types.pl falls over with TZ=Africa/Casablanca on my Linux machine, too. I'm inclined to think we ought to be translating that zone name to Europe/London instead. Or maybe we should translate to straight-up UTC? But the option of "Greenwich Daylight Time" suggests that Windows thinks this means UK civil time, not UTC. I wonder if findtimezone.c has any other surprising Windows mappings. I've never dug through that list particularly. regards, tom lane