[serhii73]

Fixes #701, part of #868 (the DATE_ORDER half, opt-in through a new setting. The date_formats half is left for a separate discussion in #868).

With DATE_ORDER set as shown:

parse(...)	"none" (default)	"year"	"all"
"32 DEC 10", DMY	2032-12-10	None	None
"10 DEC 32", MYD	2032-12-10	None	None
"13/12/10", MDY	2010-12-13	2010-12-13	None
"10 DEC 95", DMY	1995-12-10	1995-12-10	1995-12-10

The setting

STRICT_DATE_ORDER is a string. "none" keeps DATE_ORDER a preference, as on master. "year" reads a two-digit year only from the position DATE_ORDER gives the year. "all" also keeps the day and month where the order puts them, so no swap (#1431).

"year" and "all" raise a SettingValidationError if DATE_ORDER is not passed: the default one is only a preference, so there is nothing to enforce. search_dates and a reused DateDataParser are not affected. With the default PARSERS, parse() can only turn a date into None. A rejection is final across locales (ru would read "20 09 29" with MYD as a 2029 date) and skips the no-spaces parser. Only parts read from numbers are checked: "DEC 32" with DMY is still December 2032.

Stricter results under the opt-in

With "year", besides the table: an invalid month ("12/13/10" with DMY), CJK dates under an order that does not start with the year ("95年12月10日" with MDY, documented), rare orders ("40 12" with DYM), and, under YMD, YDM, MYD and DYM, a two-digit year in a position the order does not give ("DEC 10 95" with YMD, #519's "4-99" with YMD).

Known gaps

• date_formats, the other half of Given a month with 32 days, dateparser fails with some years but parses with others #868.
• search_dates without RELATIVE_BASE checks only the first date (Settings.replace() drops the explicit settings, a separate bug). A rejected span is dropped or split differently, and the dates after it resolve against the previous one, so they can change too.
• The no-spaces parser still returns a time of day for a time-only match, as on master. With a custom PARSERS that runs absolute-time first, a rejected reading can be replaced by the next parser's.
• Under MYD, a month name is not counted, so a day before the year with the month name after it ("10 95 DEC") is rejected by "year" too, although the year is in place.
• Add parse_many() to infer a shared date order #1438 also adds a STRICT_DATE_ORDER, as a bool: to agree before either lands.

Tests

127 tests; the full suite (24,606), pre-commit, mypy and the docs build pass. Differential run against master and this PR's previous head (7,683 strings × every DATE_ORDER and none × auto/en/ru/ja; 860,496 parse() and 268,800 search_dates() results):

• Unset or "none": 0 differences from master (430,248 and 134,400 compared), nor in 5,440 day ranges such as "5-5 juin 2021" in every language.
• "year", "all": no exception; every parse() change is a date becoming None (17,100 and 26,219). "all" is the "year" result or None, except "00月31日" with MYD and auto-detected languages (as before).
• "year" against the previous head: 5,632 more None, all under YMD, YDM and MYD (DMY and MDY cannot change: nothing comes after the year there). "all" is unchanged.

HISTORY.rst is left to the release PR. Suggested bullet:

- Add the ``STRICT_DATE_ORDER`` setting. With ``"year"``, a two-digit year is
  read only from the position ``DATE_ORDER`` gives the year, so "32 DEC 10" with
  ``DATE_ORDER="DMY"`` is ``None`` instead of 2032-12-10; with ``"all"``, the
  day and month are not swapped either. Both need ``DATE_ORDER`` (#868).

🤖 Generated with Claude Code

[codspeed]

Merging this PR will not alter performance

✅ 7 untouched benchmarks

---

_{Comparing fix-868-invalid-day-reordered-as-year (d2e6c6b) with master (9073f25)}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.96%. Comparing base (9073f25) to head (d2e6c6b).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1443      +/-   ##
==========================================
+ Coverage   98.94%   98.96%   +0.02%     
==========================================
  Files         239      239              
  Lines        3521     3590      +69     
==========================================
+ Hits         3484     3553      +69     
  Misses         37       37              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[AdrianAtZyte]

Any thoughts on this LLM feedback?

The analysis is great, but this is a lot of machinery for #868, and I would rather not take on the shape-matching cache and the callback plumbing into _parser for it. The DATE_ORDER check on its own looks good to me. Please, could you split that into its own PR with a few tests?

For date_formats, I am not sure the year-position approach is worth it, given the known gaps (e.g. "32 December 10" with %d %b %y still gives 2032). I wonder if we should instead discuss in #868 whether the fallback should be skipped when the string has the shape of a format.

Also, returning None for all locales on the first _MisplacedYearError feels like a separate behavior change, and 95年12月10日 with DATE_ORDER="MDY" going from a correct date to None looks like a regression to me, even if the DMY case was already wrong.

[serhii73]

Thanks, agreed on the split. I reworked this PR into the DATE_ORDER check alone (in place, to keep this thread), commit cc8afd4:

• the shape check, its cache and the callback into _parser are gone; strptime.py is untouched. The library diff is now +55/-11 in parser.py and date.py;
• tests are down to 3 tests with 28 cases, 10 of which fail on master;
• retitled and "part of Given a month with 32 days, dateparser fails with some years but parses with others #868" rather than "fixes", since the issue's own example uses date_formats.

On the other points:

date_formats. Agreed, let's take it to #868. Two things worth having in that discussion: "skip the fallback when the string has the shape of a format" needs the same shape test (strptime on the string with every digit normalised) but not the year positions, the callback or the cache, so it is much smaller. It does change the day/month swap the fallback gives today: "12/31/2020" with ["%d/%m/%Y"] is 2020-12-31 on master and would become None. And "32 December 10" with %b stays a gap under either approach, since December does not match %b.

Cross-locale finality. I kept it, because without it the fix only holds with an explicit languages. I re-ran the differential sweep (95,152 parses; DMY, MDY, YMD, MYD; auto-detected languages and en, ru, ja) with the rejection made non-final: 617 of the 8,473 rejected results, all with auto-detected languages, come back from another locale, and 583 of them as a date master never gave. zh reads "09年20月10日(日)" under DMY as a relative date (2020-06-05 from a 2020-06-15 base) and ru reads "20 09 29" under MYD as 2029-06-29, because it translates it to "29 29". The "20 09 29" test case guards this. It is narrow: only a two-digit year read from a wrong slot under an explicit DATE_ORDER is final; every other ValueError falls through to the next locale as before.

95年12月10日 with MDY. I can't separate it from "32 DEC 10" inside the parser. The ja translation is "95-12-10", so the parser sees exactly what it sees in "32-12-10" with DMY, and master's MDY result is a coincidence: the same string with DMY gives 1995-10-12. The one rule that keeps it is to check only the day slot, literally the issue's title: reject when the number read as the year sits where the order wants a day. That keeps 95年12月10日/MDY at 1995-12-10 (95 sits in the month slot) and still fixes "32 DEC 10"/DMY and "DEC 32 10"/MDY, but leaves "32/12/10"/MDY at 2032-12-10 and "12/13/10"/DMY at 2013-10-12, which are the same bug. I would rather keep the symmetric rule and list the ja case as a behaviour change, as the PR body does, but the narrower one is a small change to the same check if you prefer it.

[AdrianAtZyte]

Should we get #1419 merged first?

[AdrianAtZyte]

I think we also need to merge #1431 first.

And I think we should then rethink this PR. The documented way for DATE_ORDER to work as as a preference. If we want to be able to enforce specific date orders, we should expose some way for users to opt into that alternative behavior.

[serhii73]

Thanks! With #1419 and #1431 merged, I've rebased this onto master and reworked it along your suggestion. The check is now opt-in through a new setting, STRICT_DATE_ORDER, which defaults to False. The default is exactly master's behaviour: with the setting off, none of 527,380 results change in a differential run. The name is open, what do you think? I chose it to sit next to DATE_ORDER and mirror STRICT_PARSING.

With the setting on, the only thing it does in parse() is turn dates into None. A reading it rejects is not retried with the day and month swapped (the #1431 retry), because that would give a date the default does not. The points from your earlier review are now opt-in results, documented in docs/settings.rst and the PR body:

• 95年12月10日 with MDY is None with the setting, because its translation, 95-12-10, has nothing left to mark the year.
• The rejection stays final across locales, so ru cannot turn "20 09 29" with MYD into a date in 2029.

One question on scope: the setting enforces where the year is, but a day and month that do not fit are still swapped ("13/12/10" with MDY, and "01/13/21" with DMY through #1431). Should STRICT_DATE_ORDER also turn those swaps off, so that it enforces the whole order? That would fit the name better, but it is a bigger change, so I've left it out for now.

[AdrianAtZyte]

What if we make STRICT_DATE_ORDER an enum (string), to support all 3 approaches?

[AdrianAtZyte]

• I think "year" should check both directions, i.e. reject a two-digit year read from anywhere other than where DATE_ORDER puts it, so "10 DEC 32" with MYD becomes None too. parse error #519’s "4-99" with YMD becoming None under it is fine for an opt-in setting. That would also make it much easier to document.
• Setting STRICT_DATE_ORDER without DATE_ORDER silently does nothing. I think it should either raise a SettingValidationError, or enforce the order actually in use (the locale’s, with PREFER_LOCALE_DATE_ORDER).
• The last paragraph in docs/settings.rst could be much shorter, I think only the “only with DATE_ORDER” part and the 95年12月10日 caveat matter to users.

[AdrianAtZyte]

• Please, drop the issue numbers from the _StrictDateOrderError docstring and the #1419 comment.
• In docs/settings.rst, quote the values ('none', 'year', 'all'), and the doctests should not show a None line, since that is not what the REPL prints.