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


Reply via email to