Honor REQUIRE_PARTS for ambiguous month-number inputs by retrying year-biased DATE_ORDER
#1298
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Attempt to fix #1235.
Problem
When parsing inputs like
Oct-23withsettings={"REQUIRE_PARTS": ["month", "year"]},dateparser.parsecan returnNoneeven though a valid interpretation exists (October 2023). The failure occurs because the initialDATE_ORDER(often locale-derived or the default) may interpret the trailing number as a day rather than a year, causingREQUIRE_PARTSvalidation to reject the result.Fix
When all of the following are true:
REQUIRE_PARTSincludes"year"and does not require"day",DATE_ORDER,We retry parsing the same translated string with year-biased
DATE_ORDERcandidates (MYD, thenYMD) after the initial attempt. This allows ambiguousMon-23style inputs to resolve to month–year when that is the only way to satisfy the requested parts.Scope / compatibility
REQUIRE_PARTS.DATE_ORDERis explicitly set by the caller.REQUIRE_PARTSrequiresday(month–day remains valid).