How does it make things faster of it's the same as the first search path in the default list?

It would make failed lookups fail faster, e.g. if I call `ZoneInfo('America/NewYork')`, it will fail to find that in `/usr/share/zoneinfo`, then it will search the rest of the TZ path. I don't think it would make a *meaningful* difference in speed in this unusual situation, but it is extra unnecessary work.

The main reason I'd say to include this change would be because the other locations don't need to be there. They're included because CPython doesn't know where it's being deployed, but the Arch Linux version does know this, and can specify where it deploys time zones.

A more realistic bug that this helps to combat:

- Something ends up deploying tzdata 2018a or something to `/etc/zoneinfo`, and then never updates it (because it was a mistake or an artifact of some old workflow not run anymore).
- Someone writes some code that uses `ZoneInfo("CET")` or one of the deprecated legacy zones.
- Upstream tzdata decides that the deprecated legacy zones have been deprecated for long enough and makes a release that doesn't include them.
- The program starts falling back to 2018a whenever CET is used, which causes the application to silently return incorrect data.

Another possibly realistic bug that this would solve would be if something deploys old time zone data to one of the incorrect default locations and an application is run in a configuration that doesn't have permissions to access /usr/share/zoneinfo but *does* have permissions to access the incorrect default location. They would silently fall back to using the old time zone data and not even realize it, whereas with this patch, they would get an exception (which they could resolve by fixing permissions or by running with `PYTHONTZPATH=/etc/zoneinfo`.

Arch doesn't tend to actively try to prevent user error.

I'm not sure what the problem would be here.

This is not a high-priority issue, but it *is* the intended deployment mechanism for Python. The default time zone path is intended for builds where you don't know the location of the zoneinfo data when you are doing the build. The `--with-tzpath` parameter was explicitly added for the purpose of allowing packagers to specify where the zoneinfo files are located because upstream we don't have enough information to do it in the targeted fashion we'd prefer.

It is true that the default configuration is sufficiently well-aligned with the way Arch Linux does things that it is very unlikely to cause issues if left alone, but on the other hand, I don't see any real downsides here, and the --with-tzpath version is more robust. There's no patch to maintain and this is very much still a vanilla Python distribution.

The only problem I could imagine this causing is that it relies on Arch's tzdata package deploying to /usr/share/zoneinfo instead of one of the other default locations — if Arch moved tzdata so it was deployed elsewhere, Python would start failing. Still, I think this is actually a desirable state of affairs, because if Arch *were* to move tzdata's deployment location, then the python package should *at least* be putting Arch's preferred deployment location at the front of the list. With my patch, `python`'s check() should fail for lack of time zone data, whereas without the patch, `zoneinfo.ZoneInfo` calls would just get slightly slower.

The file becomes slightly smaller and therefore faster to load, clearly this is a win of some kind even if not very much, let's be happy with it. :)

It is also "more correct" and therefore good to do, even if as you say it's not high priority, and the ticket is assigned, so this will almost certainly at some point be done.