BUG: warning shown when parsing delimited date string even if users can't do anything about it

[MarcoGorelli]

• closes WARN: warning shown when parsing delimited date string even if users can't do anything about it #50231 (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.

[mroeschke]

LGTM

[jbrockmendel]

are there any contexts where we do want to issue a warning?

[MarcoGorelli]

I wouldn't think so, because users can't pass format nor dayfirst to Timestamp

If anything, maybe Timestamp should become stricter and only accept iso8601 strings?

[jbrockmendel]

I wouldn't think so, because users can't pass format nor dayfirst to Timestamp

i meant more along the lines of if the warning should be issued when we are parsing sequences. (so it would need to be issued somewhere else presumably)

[MarcoGorelli]

Timestamp doesn't accept sequences, and to_datetime already warns - I've probably misunderstood though, is there another path that accepts sequences that might get here? I'll check more carefully tomorrow

[jbrockmendel]

and to_datetime already warns

wasnt aware of that. all good here.

[jbrockmendel]

If anything, maybe Timestamp should become stricter and only accept iso8601 strings?

id be OK with more strict than the status quo (problems have been caused by the parsing code accepting "t2m", though Timestamp still rejects that as OOB for nanosecond reso). iso8601-only is probably too strict for my tastes

long long ago i wrote a dateutil-like parser that passed all/most of the dateutill tests and IIRC it was mostly just a handful of regexes (and appreciably more performant). ill see if i can dig that up.

[MarcoGorelli]

and to_datetime already warns

wasnt aware of that. all good here.

thanks! merging then