Datetime parsing shouldn't assume YYYY-DD-MM regardless of locale

[CrossR]

Hi,

I think #762 is causing me some issues with my scripts.

I'm a UK user, and it is now processing my dates as day first, which would be good....but I'm passing them as YYYY-MM-DD, rather than DD-MM-YYYY. My entries for this week (3rd Nov / 03-10-2024), are being added as 10th March which isn't ideal.

I can totally reformat the scripts to move to DD-MM-YYYY, but YYYY-MM-DD is obviously a fairly common programming format, so having specific support to ignore the locale and use that would likely be useful for many people, as it is the default I get from various APIs etc.

I can see there is a comment on that PR around a manual override and/or in-app hints etc, so maybe this would be covered by that, but I think a --iso-format or whatever flag would be useful, if it isn't too much work.

For now, I've manually added export LC_TIME="en_US" to my script, to swap back to the older behaviour, so it isn't a pressing issue, just a nice to have!

[dbarnett]

Ah sorry for that!

I agree YYYY-MM-DD should be assumed over YYYY-DD-MM regardless of locale. I guess the parsing library controls both using the same dayfirst flag? (Really disappointed with locale handling in these libraries… 🫤).

I think if the detection is working fine but the dayfirst override is too aggressive, I may just need to preprocess the dates passed to parsing and special-case so only ones that start with XX-XX- get the dayfirst option applied.

[dbarnett]

Confirmed, dateutil's dayfirst arg has silly behavior:

from dateutil.parser import parse
>>> parse('2000-01-02')
datetime.datetime(2000, 1, 2, 0, 0)
>>> parse('2000-01-02', dayfirst=True)
datetime.datetime(2000, 2, 1, 0, 0)

I'll try to special-case that to more reasonable defaults...

In the meantime, +1 for your workaround, anyone affected can use export LC_TIME="en_US" to opt out of whole date parsing change.

[dbarnett]

K the fix is kinda ugly but it's merged. I'm going to include it in a 4.5.1 release soon.