Repository navigation
ZoneInfo object raises OSError instead of ZoneInfoNotFoundError for timezone input larger than 255 characters #96463
Description
Activity
I cannot reproduce it on macos. I've tried
3.10,3.11, and3.12. The result is:>>> from zoneinfo import ZoneInfo >>> ZoneInfo("a"*256) Traceback (most recent call last): File "/Users/sobolev/.pyenv/versions/3.10.0/lib/python3.10/zoneinfo/_common.py", line 12, in load_tzdata return importlib.resources.open_binary(package_name, resource_name) File "/Users/sobolev/.pyenv/versions/3.10.0/lib/python3.10/importlib/resources.py", line 43, in open_binary package = _common.get_package(package) File "/Users/sobolev/.pyenv/versions/3.10.0/lib/python3.10/importlib/_common.py", line 66, in get_package resolved = resolve(package) File "/Users/sobolev/.pyenv/versions/3.10.0/lib/python3.10/importlib/_common.py", line 57, in resolve return cand if isinstance(cand, types.ModuleType) else importlib.import_module(cand) File "/Users/sobolev/.pyenv/versions/3.10.0/lib/python3.10/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1050, in _gcd_import File "<frozen importlib._bootstrap>", line 1027, in _find_and_load File "<frozen importlib._bootstrap>", line 992, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed File "<frozen importlib._bootstrap>", line 1050, in _gcd_import File "<frozen importlib._bootstrap>", line 1027, in _find_and_load File "<frozen importlib._bootstrap>", line 1004, in _find_and_load_unlocked ModuleNotFoundError: No module named 'tzdata' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Users/sobolev/.pyenv/versions/3.10.0/lib/python3.10/zoneinfo/_common.py", line 24, in load_tzdata raise ZoneInfoNotFoundError(f"No time zone found with key {key}") zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
Trying
docker run --rm -it python:3.10.4-bullseye. And result is the same.
Can you please provide more information? Maybe you have some extra settings for the filesystem?Hi,
I think the absence of
tzdatapackage somehow hides the problem I'm describing originally probably due to exiting sooner. When installingtzdatathe error appears. Apologies I missed this info on the original report.I tried
docker run --rm -it python:3.10.4-bullseye /bin/sh -c "python -m pip install tzdata && python"with the reproduction code and the error appears also in docker.Thanks, now I can see this error.
I am trying to reproduce it in our CI to learn abouttzdatapackage in our buildbots. No luck for now.But, in the mean time: can you please explain how practical is it to catch this exception?
Are there any timezones that are longer than 255 chars? Maybe this exception should be propagated: it might indicate issues with file system or permissions.There are too many use-cases for
OSErrorto catch it blindly.You are correct blindly catching
OSErroris not really good and I am not sure what should be the best course of action here. In practice so long timezones shouldn't exist, but if some input reaches this function and is that long somebody implementing only what the documentation mentions might end up with unhandled exceptions (this is how I found this actually from stress testing my application). Maybe a change in the documentation might suffice here, mentioningOSErroras a possible exception and propagating this as you described also sounds good.Technically, since this data comes from the
Traversableabstraction (see importlib.resources), which may be user defined and makes no guarantees about which exceptions can be raised, anything could be raised here. IMO we should probably blindly catch all (normal) exceptions and stack them withZoneInfoNotFoundError.@pganssle do you have any thoughts regarding this?
Here's another case where this happens: on Windows, there are a number of characters that are apparently not allowed in file names, and can generate OSErrors with errno=22 (EINVAL).
On Windows:
from zoneinfo import ZoneInfo ZoneInfo("*")
elicits an
OSError: [Errno 22] Invalid argument.A string containing any of the characters "*", "<", ">", ":", '"', "?" or any of the control characters "\x01" through "\x1f" will work to elicit the EINVAL.
There's repo with a small, trivial test here: https://github.com/dairiki/zoneinfo-bug/
GitHub workflow test matrix results here: https://github.com/dairiki/zoneinfo-bug/actions/runs/4300480361
show failures under Windows for all tested python versions (3.9.13, 3.10.10, 3.11.2, 3.12.0-alpha.5).255 bytes is the max filename length on certain OSs.
There does not seem to be a defined maximum but from what I can tell 255 would defiantly cover all, maybe just limiting it to that would suffice. SO I can open a PR for this.
Bug report
According to documentation all calls to ZoneInfo should raise
ValueErrororZoneInfoNotFoundError.Creating a ZoneInfo object with an invalid very long timezone (length > 255) an OSError is raised instead (
OSError: [Errno 36] File name too long).I believe that
cpython/Lib/zoneinfo/_common.py
Lines 11 to 24 in 29f1b0b
OSErrorexception raised by open and reraise it toZoneInfoNotFoundError.Sample code for reproduction:
Your environment
Linked PRs
load_tzdataraisingOSError, not `ZoneInfoNotFound… #99602