[Python][CI] test_string_to_tzinfo_pytz_fallback fails on verify-rc-source-windows

[raulcd]

Describe the bug, including details regarding any error messages, version, and platform.

The verify-rc-source-windows job is currently failing with:

================================== FAILURES ===================================
_____________________ test_string_to_tzinfo_pytz_fallback _____________________

    @pytest.mark.skipif(
        sys.platform == 'darwin', reason="macOS supports those lower-case names"
    )
    def test_string_to_tzinfo_pytz_fallback():
        pytz = pytest.importorskip("pytz")
        result = pa.lib.string_to_tzinfo("europe/brussels")
        expected = pytz.timezone("Europe/Brussels")
>       assert result == expected
E       AssertionError: assert zoneinfo.ZoneInfo(key='europe/brussels') == <DstTzInfo 'Europe/Brussels' LMT+0:18:00 STD>

C:\tmp\arrow-verify-release\conda-env\lib\site-packages\pyarrow\tests\test_types.py:521: AssertionError

This is related to:

• GH-15047: [Python]: switch from pytz to zoneinfo by default for string to tzinfo conversion #49694

Component(s)

Continuous Integration, Python

[raulcd]

@jorisvandenbossche @AlenkaF any idea?

[AlenkaF]

From a quick look I would think zoneinfo on Win is using tzdata package and that the versions of tzdata are different between the CI build and the verification job: version 2025 in the verification and 2026 in the CI build. Seems like the newer version does not accept europe/brussels string and falls back to pytz, but the older version supports the lower case string.

It would be great if this would be supported for newer versions of tzdata, I think, so we would not need to depend on pytz in this case?

[jorisvandenbossche]

It would be great if this would be supported for newer versions of tzdata, I think, so we would not need to depend on pytz in this case?

I don't think we have to care too much about this (users should simply not use lower case versions, if they want to have robust timezone metadata).

I added this test to specifically test this "fallback to pytz if some string is not supported by zoneinfo" logic, so I was specifically looking for such a case. But clearly this case is not robust enough given it does not hold on various platforms ..

I can maybe verify first that the specific string is not accepted by zoneinfo, before the assert. That should make the test more robust.

[AlenkaF]

Yeah, seems reasonable to me.

[raulcd]

Issue resolved by pull request 50042
#50042