Python 3.9 PytzUsageWarning

[kkoehncke]

When upgrading to Python 3.9, getting the following warning:

Python 3.9.5 (default, Jun  4 2021, 12:28:51)
[GCC 7.5.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dateparser
>>> dateparser.parse("2021-08-02")
/opt/conda/lib/python3.9/site-packages/dateparser/date_parser.py:35: PytzUsageWarning: The localize method is no longer necessary, as this time zone supports the fold attribute (PEP 495). For more details on migrating to a PEP 495-compliant implementation, see https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html
  date_obj = stz.localize(date_obj)
datetime.datetime(2021, 8, 2, 0, 0)

Is there an anticipated fix for this or a way to suppress this?

Thanks!

[viseshrp]

is there a way to silence these warnings temporarily?

[FinnWoelm]

Hi @viseshrp,

I was able to temporarily silence these warnings with:

import warnings
import dateparser

# Ignore dateparser warnings regarding pytz
warnings.filterwarnings(
    "ignore",
    message="The localize method is no longer necessary, as this time zone supports the fold attribute",
)

# Your code ...

SO thread on filtering Python warnings: https://stackoverflow.com/a/56142903/6451879

---

For pytest, you can modify pytest.ini like this:

[pytest]
filterwarnings = 
    ignore:The localize method is no longer necessary, as this time zone supports the fold attribute

[viseshrp]

Hi @viseshrp,

I was able to temporarily silence these warnings with:

import warnings
import dateparser

# Ignore dateparser warnings regarding pytz
warnings.filterwarnings(
    "ignore",
    message="The localize method is no longer necessary, as this time zone supports the fold attribute",
)

# Your code ...

SO thread on filtering Python warnings: https://stackoverflow.com/a/56142903/6451879

For pytest, you can modify pytest.ini like this:

[pytest]
filterwarnings = 
    ignore:The localize method is no longer necessary, as this time zone supports the fold attribute

Thanks!

[ElijahSink]

For some reason the filterwarnings configuration mentioned above didn't work for me.
Here's what I used:

# pyproject.toml
[tool.pytest.ini_options]
filterwarnings = ["ignore::pytz_deprecation_shim.PytzUsageWarning"]

[KevinMGranger]

This occurs in 3.10 as well.

[bsekiewicz]

Why we can't replace this

dateparser/dateparser/date_parser.py

Lines 33 to 37 in 4490ca6

	stz = get_localzone()
	if hasattr(stz, 'localize'):
	date_obj = stz.localize(date_obj)
	else:
	date_obj = date_obj.replace(tzinfo=stz)

with this

stz = get_localzone()
date_obj = date_obj.replace(tzinfo=stz)

???

Definition of localize is equivalent (???) - https://github.com/pganssle/pytz-deprecation-shim/blob/47bd4bdd9346cafa6c6d66817082ccce099890ad/src/pytz_deprecation_shim/_impl.py#L205

[DavidMStraub]

Hi,

I suspect the cause of the issue is a change in tzlocal a few months ago (source):

With version 3.0 of tzlocal, tzlocal no longer returned pytz objects, but zoneinfo objects, which has a different API. Since 4.0, it now restored partial compatibility for pytz users through Paul Ganssle’s pytz_deprecation_shim.

A second problem could be that dateparser, according to its readme, aims to be compatible with Python 3.5+, but 3.5 was before PEP 495 was introduced.

Since even Python 3.6 has reached EOL in the meantime, I suggest dropping at least Python 3.5 support and implementing @bsekiewicz's suggestion.

[DavidMStraub]

I suggest dropping at least Python 3.5 support

I realized tzinfo itself requires 3.6+, so 3.5 support is anyway gone. So just an update of the Readme is needed for this.

[akash-cis]

I faced the same issue with dateparser. passing a timezone to the parse method solved that error for me.
dateparser.parse(value, settings={'TIMEZONE': 'UTC'})

you can read all about the by this documentation https://pypi.org/project/dateparser/

[dreki]

You can also add a timezone in the string you're parsing as well.

E.g. instead of dateparser.parse('2022-04-13’), do dateparser.parse('2022-04-13 Z’)

[Gallaecio]

Fixed by #1062