BUG: Spurious "FutureWarning: Use pd.to_datetime instead."

[lafrech]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import io
import datetime as dt

import pandas as pd


csv_file = io.StringIO("Timestamp,Value\n2020-01-01T00:00:00,12")

def to_aware_datetime(timestamp_str):
    timestamp_dt = pd.to_datetime(timestamp_str)
    if timestamp_dt.tzinfo is None:
        raise Exception("Timestamps must be TZ-aware")
    return timestamp_dt.astimezone(dt.timezone.utc)

data_df = pd.read_csv(
    csv_file,
    index_col=0,
    parse_dates=True,
    date_parser=to_aware_datetime,
)

Issue Description

A warning is raised:

test.py:16: FutureWarning: 
        Use pd.to_datetime instead.

I think the root cause is that while trying to support several different use cases, converter (in base_parser.py) catches Exception a bit too broadly without letting user-generated exceptions bubble-up, until it defaults to calling deprecated generic_parser which causes the warning.

I guess Exception was used because it was complicated to list all possible exceptions. Beside, even if a more selective list was used, user exceptions derived from exceptions in that list would be caught anyway, so the issue is inherent to the trial and error pattern.

The problem may disappear when generic_parser is removed and the last exception is not caught.

The point is that I had a hard time finding out the cause of the warning (and I'm still not even sure I finally understood).

Expected Behavior

No deprecation warning.

Installed Versions

INSTALLED VERSIONS

commit : e8093ba
python : 3.9.2.final.0
python-bits : 64
OS : Linux
OS-release : 5.10.0-15-amd64
Version : #1 SMP Debian 5.10.120-1 (2022-06-09)
machine : x86_64
processor :
byteorder : little
LC_ALL : None
LANG : fr_FR.UTF-8
LOCALE : fr_FR.UTF-8

pandas : 1.4.3
numpy : 1.21.5
pytz : 2022.1
dateutil : 2.8.2
setuptools : 57.4.0
pip : 22.1.2
Cython : None
pytest : 7.1.2
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : 2.9.3
jinja2 : 3.1.2
IPython : None
pandas_datareader: None
bs4 : None
bottleneck : None
brotli : None
fastparquet : None
fsspec : None
gcsfs : None
markupsafe : 2.1.1
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
snappy : None
sqlalchemy : 1.4.32
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
zstandard : None

[phofl]

Hi, thanks for your report.

This happens because we are catching the exception and retry with a deprecated method. Not sure what to do here exactly

[lafrech]

Yeah, what I thought. I figured it was worth reporting but as I wrote, I don't know what can be done.

Feel free to close as WONTFIX.

Well, it is just a warning. If the exception bubbles up the day the deprecated method is removed, then it should be fine.

[mroeschke]

Thanks for the report. This warning could be filtered and released in 1.5, but our next release will be 2.0 in which we would subsequently remove generic_parser and the added warning. I'm inclined to say it's not worth the code churn just to suppress a warning.

[phofl]

This works now since the generic parser has been removed