[Doc] tzdata error due to a lack of a discoverable system timezone database

[shr3yas-k]

Describe the enhancement requested

Some timezone-dependent PyArrow tests require a discoverable system timezone database (tzdata / zoneinfo).

On environments without standard filesystem layouts (e.g. non-FHS compliant systems or minimal containers), these tests can fail with errors like:

ArrowInvalid: Cannot locate or parse timezone 'CET' discover_tz_dir failed to find zoneinfo

There have been several mitigations over time like older interim fixes for Windows itself (#36996), PR #45425, and recent Windows CI fixes such as commit ab2c0ad.

Windows-specific failures appear to be largely handled now, but the underlying requirement and expected behavior are not documented for contributors on other platforms (e.g. non-FHS systems and hermetic environments).

Happy to follow up with a small documentation PR if this sounds reasonable. The goal would be to clarify that these failures are environment-related and expected in certain setups, rather than indicating a bug in Arrow itself.

Component(s)

Documentation

[rok]

@shr3yas-k did you want to improve existing documentation or add something new?

[shr3yas-k]

Yeah, I’d like to improve the docs by adding a short note explaining that this is environment related rather than a bug. I ran into it myself while testing locally on NixOS, so the idea is mainly to make this clearer for contributors on non-standard environments.

[rok]

Oh NixOS, interesting! Where are you installing pyarrow from?

[shr3yas-k]

I used Miniforge3 to setup conda-forge and I cloned the apache arrow repo locally and everything after that was according to the standard python-development workflow for pyarrow.

[rok]

Do you currently still see this issue? @h-vetinari has recently backported a fix for windows on conda-forge: #48601 (comment) and can perhaps advise here too.

[h-vetinari]

Well the main thing AFAICT is that #48601 hasn't been merged yet. I backported this not so much for fun, but because there was no realistic way to unbreak CI after a latent build script bug had hidden the failure for a while. If I could, I would have chosen a less invasive change; luckily it only affected v22/v23, but yeah, the main branch here (much less v23 as tagged) is still not functional most likely (c.f. #48874).

[rok]

@shr3yas-k given the current state it then makes sense to document this. Do please check where we currently document tz data related things and add new documentation there if it makes sense.