ZoneInfo object raises OSError instead of ZoneInfoNotFoundError for timezone input larger than 255 characters

Bug report

According to documentation all calls to ZoneInfo should raise ValueError or ZoneInfoNotFoundError.
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

    
           try: 
        
               return resources.files(package_name).joinpath(resource_name).open("rb") 
        
           except (ImportError, FileNotFoundError, UnicodeEncodeError): 
        
               # There are three types of exception that can be raised that all amount 
        
               # to "we cannot find this key": 
        
               # 
        
               # ImportError: If package_name doesn't exist (e.g. if tzdata is not 
        
               #   installed, or if there's an error in the folder name like 
        
               #   Amrica/New_York) 
        
               # FileNotFoundError: If resource_name doesn't exist in the package 
        
               #   (e.g. Europe/Krasnoy) 
        
               # UnicodeEncodeError: If package_name or resource_name are not UTF-8, 
        
               #   such as keys containing a surrogate character. 
        
               raise ZoneInfoNotFoundError(f"No time zone found with key {key}")

should also handle the OSError exception raised by open and reraise it to ZoneInfoNotFoundError.

Sample code for reproduction:

from zoneinfo import ZoneInfo
ZoneInfo("a"*256)

Your environment

CPython versions tested on: Python 3.10.4
Operating system and architecture: Debian GNU/Linux 11 (bullseye)

Linked PRs

gh-96463: fix load_tzdata raising OSError, not `ZoneInfoNotFound… #99602

I cannot reproduce it on macos. I've tried 3.10, 3.11, and 3.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 tzdata package somehow hides the problem I'm describing originally probably due to exiting sooner. When installing tzdata the 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.

pythongh-96463: fix `load_tzdata` raising `OSError`, not `ZoneInfoNot…

Thanks, now I can see this error.
I am trying to reproduce it in our CI to learn about tzdata package 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 OSError to catch it blindly.

Related #85702 and #84683

You are correct blindly catching OSError is 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, mentioning OSError as a possible exception and propagating this as you described also sounds good.

@pganssle

Technically, since this data comes from the Traversable abstraction (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 with ZoneInfoNotFoundError.

@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.

Navigation Menu

Repository navigation

ZoneInfo object raises OSError instead of ZoneInfoNotFoundError for timezone input larger than 255 characters #96463

Bug report

Your environment

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	try:
	return resources.files(package_name).joinpath(resource_name).open("rb")
	except (ImportError, FileNotFoundError, UnicodeEncodeError):
	# There are three types of exception that can be raised that all amount
	# to "we cannot find this key":
	#
	# ImportError: If package_name doesn't exist (e.g. if tzdata is not
	# installed, or if there's an error in the folder name like
	# Amrica/New_York)
	# FileNotFoundError: If resource_name doesn't exist in the package
	# (e.g. Europe/Krasnoy)
	# UnicodeEncodeError: If package_name or resource_name are not UTF-8,
	# such as keys containing a surrogate character.
	raise ZoneInfoNotFoundError(f"No time zone found with key {key}")

ZoneInfo object raises OSError instead of ZoneInfoNotFoundError for timezone input larger than 255 characters #96463

Description

Bug report

Your environment

Linked PRs

Activity

sobolevn commented on Nov 19, 2022

lleontop commented on Nov 19, 2022

sobolevn commented on Nov 20, 2022

sobolevn commented on Nov 20, 2022

lleontop commented on Nov 20, 2022

FFY00 commented on Dec 15, 2022

dairiki commented on Mar 1, 2023

StanFromIreland commented on Mar 15, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions