BUG: pandas.to_datetime reports incorrect index when failing.

[flownt]

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

pandas as pd
valid = '2024-01-01'
invalid = 'N'
S = pd.Series([valid]*45_000 + [invalid])
T = pd.to_datetime(S, format='%Y-%m-%d', exact=True) 

################################
# Traceback redacted.
################################
ValueError: time data "N" doesn't match format "%Y-%m-%d", at position 1. You might want to try:
    - passing `format` if your strings have a consistent format;
    - passing `format='ISO8601'` if your strings are all ISO8601 but not necessarily in exactly the same format;
    - passing `format='mixed'`, and the format will be inferred for each element individually. You might want to use `dayfirst` alongside this.

Issue Description

As you can see a ValueError is raised. That is fine.

The description says it happens for item at postition 1, however, which is not correct. It happens for item at position 45000.

Expected Behavior

The correct position would be reported to the user. I'd like to do S[] and be able to see why it raised valueError.

Installed Versions

INSTALLED VERSIONS

commit : d9cdd2e
python : 3.11.8.final.0
python-bits : 64
OS : Linux
OS-release : 6.9.7-amd64
Version : #1 SMP PREEMPT_DYNAMIC Debian 6.9.7-1 (2024-06-27)
machine : x86_64
processor :
byteorder : little
LC_ALL : None
LANG : C.UTF-8
LOCALE : en_US.UTF-8

pandas : 2.2.2
numpy : 2.0.1
pytz : 2024.1
dateutil : 2.9.0.post0
setuptools : 68.1.2
pip : 24.1.1
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : None
pandas_datareader : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : None
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
python-calamine : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2024.1
qtpy : None
pyqt5 : None

[Lollitor]

Hi,
I noticed this issue and I'd like to help triage and potentially fix it. Is it okay if I proceed with investigating this bug?
Thanks!

[flownt]

Sure! From the outside I would guess the series is processed in batches and accidentally the numeric index into the batch is returned instead of the index of the series element. If you play with the the length of the valid list you'll notice it jumping around but rarely being correct.

[Lollitor]

Thank you for the insight! I will look into this and investigate further, after I will update here. Appreciate the guidance!

[rhshadrach]

Thanks for the report. It appears to me that duplicates are first removed from the values. It seems easiest to just remove the index from the error message. Further investigations and PRs to fix are welcome!

[KevsterAmp]

Take

[KevsterAmp]

I'd like to work on this, thanks

[flownt]

Thanks for the report. It appears to me that duplicates are first removed from the values. It seems easiest to just remove the index from the error message. Further investigations and PRs to fix are welcome!

I took some time to look into the code and this seems correct.

The error message comes from:

array_strptime in pandas/pandas/_libs/tslibs/strptime.pyx

which appears to be called indirectly from pandas/pandas/core/tools/datetimes.py:1015

The cause appears to be as @rhshadrach said: the series is first deduplicated by _maybe_cache and only then the date-parsing is applied.

The branches at 1023 and 1029 appear to also be affected.

As a pandas.Series has an index it seems most consistent to me to report the item causing the error by the index.

[maushumee]

Thanks for the report. It appears to me that duplicates are first removed from the values. It seems easiest to just remove the index from the error message. Further investigations and PRs to fix are welcome!

Just reproduced the issue and looks like this is the cause. I would like to contribute towards the fix.

[maushumee]

take