Pandas version checks

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

  • [X] 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 : e8093ba372f9adfe79439d90fe74b0b5b6dea9d6 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

Comment From: 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

Comment From: 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.

Comment From: 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.

Comment From: phofl

This works now since the generic parser has been removed