CI: avoid guess_datetime_format failure on 29th of Feburary

[MarcoGorelli]

• closes BUG: List of years (as string) raises UserWarning with to_datetime #57672 (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

[MarcoGorelli]

the guessed format is checked explicitly against the input:

pandas/pandas/_libs/tslibs/parsing.pyx

Lines 1050 to 1061 in 7bdb6d8

	try:
	array_strptime(np.asarray([dt_str], dtype=object), guessed_format)
	except ValueError:
	# Doesn't parse, so this can't be the correct format.
	return None
	# rebuild string, capturing any inferred padding
	dt_str = "".join(tokens)
	if parsed_datetime.strftime(guessed_format) == dt_str:
	_maybe_warn_about_dayfirst(guessed_format, dayfirst)
	return guessed_format
	else:
	return None

so this should be safe

[jbrockmendel]

worth adding a comment about why this default was chosen?

[MarcoGorelli]

sure, thanks

[jbrockmendel]

Looks reasonable. I guess it would be a PITA to write a test?

[MarcoGorelli]

Looks reasonable. I guess it would be a PITA to write a test?

given that the function calls datetime.now from Cython - yes, probably

[datapythonista]

I fail to understand what's going on. Surely happy to get this merged if it fixes the problem and you understand what's going on.

The root problem seems to be that guess_datetime_format('2003') is None instead of %Y. That would be easy to test if we want. What I don't understand is why changing the day and the month in the parsed date is relevant if the only token we have is the year...

>>> dateutil.parser.parse('2003', dayfirst=True, default=datetime.datetime.now().replace(hour=0, minute=0, second=0, microsecond=0))
datetime.datetime(2003, 2, 28, 0, 0)
>>> dateutil.parser.parse('2003', dayfirst=True, default=datetime.datetime(1970, 1, 1))
datetime.datetime(2003, 1, 1, 0, 0)

I didn't debug it, I guess you did, but I can't see why in the implementation it should make a difference. As said, if you are confident that this is a good solution and the algorithm is relivable happy to get this merged. But seems like there is a bug in the algorithm below we are not preventing/hacking, no?

[MarcoGorelli]

yeah seems like there's something in pandas' vendored code which makes dateutil_parse fail, even though non-vendored dateutil itself parses it. that's the problem with vendoring I guess...

[rhshadrach]

@datapythonista - currently in main we take today's date, replace it with the bits that the user passed, and then check if it's a valid date. E.g. "2002" on 2/29 becomes "2002-02-29" which is not a valid date. From this we conclude we've somehow guessed wrong.

[datapythonista]

Thanks both. I see, I assumed dateutil_parse was an alias to the dateutil parser. I see the copied version has the comment lifted from dateutil to get resolution, maybe the dateutil parser works at second resolution and we work at microsecond or nanosecond, and that's why the function was copied to pandas?

In any case I think the fix is fine, a function to get the format from a partial date is surely not going to be perfect anyway.

[mroeschke]

Looks good. Could you double check this typing issue? https://github.com/pandas-dev/pandas/actions/runs/8108693644/job/22162385490?pr=57674

[MarcoGorelli]

thanks - that one should be addressed in #57689

[mroeschke]

LGTM. Going to retarget for 3.0 since the next time this will fail is in 4 years by which 2.2.x will be unsupported :)

[mroeschke]

Thanks @MarcoGorelli