fix: Apply PREFER_DATES_FROM logic to custom date formats (Fixes #445)

[adnan-awan]

Description

Fixes #445 - The settings.PREFER_DATES_FROM setting now correctly applies when date_formats are explicitly specified with 2-digit year formats (%y).

Problem

Previously, when date_formats parameter was provided to dateparser.parse(), the PREFER_DATES_FROM setting had no effect on 2-digit year parsing:

# Before fix:
dateparser.parse('1/15/64', 
                  date_formats=['%m/%d/%y'], 
                  settings={'PREFER_DATES_FROM': 'past'})
# Returned: datetime(2064, 1, 15) ❌ (should be 1964)

dateparser.parse('1/15/64', 
                  settings={'PREFER_DATES_FROM': 'past'})
# Returned: datetime(1964, 1, 15) ✅ (correct)

Root Cause

When date_formats were provided, the parser would directly use Python's datetime.strptime() without applying the PREFER_DATES_FROM logic. This caused ambiguous 2-digit years to be interpreted in the wrong century.

Solution

Enhanced the parse_with_formats() function in dateparser/date.py to:

1. Detect when a 2-digit year format (%y) is used in date_formats
2. Apply the same year adjustment logic as the regular parser based on PREFER_DATES_FROM setting:
   • If parsed date is in the future and PREFER_DATES_FROM='past', subtract 100 years
   • If parsed date is in the past/equal and PREFER_DATES_FROM='future', add 100 years
3. Only apply this logic for 2-digit year formats, not 4-digit formats (%Y)

Changes

• dateparser/date.py: Enhanced parse_with_formats() function with PREFER_DATES_FROM logic
• tests/test_date_parser.py: Added 5 comprehensive test cases covering:
  • PREFER_DATES_FROM='past' with 2-digit year (original issue)
  • PREFER_DATES_FROM='future' with 2-digit year
  • Past date with future preference
  • Future date with past preference
  • 4-digit year format (ensures it's unaffected)

Testing

✅ All 24,056 existing tests pass (8 skipped, 1 xfailed)
✅ 5 new test cases specifically for this fix

Test Coverage

• Verified PREFER_DATES_FROM='past' now works with date_formats
• Verified PREFER_DATES_FROM='future' works correctly
• Verified 4-digit year formats are not affected by this change
• Verified edge cases with different year values

Before/After

# After fix - Both now return correct result:
dateparser.parse('1/15/64', 
                  date_formats=['%m/%d/%y'], 
                  settings={'PREFER_DATES_FROM': 'past'})
# Returns: datetime(1964, 1, 15) ✅

dateparser.parse('1/15/64', 
                  settings={'PREFER_DATES_FROM': 'past'})
# Returns: datetime(1964, 1, 15) ✅

Code Quality

• Follows existing code patterns in the codebase
• Minimal, focused changes with clear intent
• No breaking changes to existing functionality
• Consistent with similar logic in dateparser/parser.py

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.12%. Comparing base (08c78d3) to head (d496385).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1342      +/-   ##
==========================================
+ Coverage   97.11%   97.12%   +0.01%     
==========================================
  Files         235      235              
  Lines        2909     2924      +15     
==========================================
+ Hits         2825     2840      +15     
  Misses         84       84              

☔ 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]

💄 elif

[AdrianAtZyte]

Sonnet says we are not supposed to be using datetime.today() here:

The NLP path in parser.py:434-436 computes self.now from settings.RELATIVE_BASE, and uses that for the comparison. The PR uses datetime.today() unconditionally. This means RELATIVE_BASE is silently ignored in the date_formats path — an inconsistency that would surprise users who set a custom base for testing or time-shifted parsing

Could you check?

[AdrianAtZyte]

I see it done somewhere else in the code base, but I wonder why we use in to compare here. It is a string, not a set, maybe == is the right call?

[AdrianAtZyte]

From Opus:

Bugs I confirmed by running it

1. Crash on timezone-aware RELATIVE_BASE (regression):
parse('1/15/64', date_formats=['%m/%d/%y'],
      settings={'PREFER_DATES_FROM':'past', 'RELATIVE_BASE': datetime(1980,1,1,tzinfo=timezone.utc)})
# TypeError: can't compare offset-naive and offset-aware datetimes
The NLP path handles the same input fine (returns 1964), and the pre-PR code returned 2064. So the new path is strictly less robust. date_obj from strptime is naive; an aware RELATIVE_BASE breaks the now < date_obj comparison.

2. Crash on Feb 29 century shift to a non-leap year (regression):
parse('2/29/00', date_formats=['%m/%d/%y'], settings={'PREFER_DATES_FROM':'future'})
# ValueError: day is out of range for month   (2000-02-29 → replace(year=2100), and 2100 isn't leap)
parser.py guards this elsewhere with _get_correct_leap_year; the new code calls date_obj.replace(year=...) unguarded. NLP returns None here rather than crashing.

3. The "respects RELATIVE_BASE" claim is overstated. It's only honored for the century pivot. The missing-year branch still uses real datetime.now().year:
parse('1/15', date_formats=['%m/%d'], settings={'RELATIVE_BASE': datetime(1980,1,1)})
# → 2026-01-15, not 1980
Pre-existing, but it contradicts the commit message and is internally inconsistent.

Design notes

- Logic duplication. This is now a third near-copy of the same century rule. It's a reasonable pragmatic choice (unifying the paths is a big refactor), but the two will drift. A shared helper (e.g. _apply_century_preference(date_obj, now, prefer)) used by both date.py and parser.py would fix #1/#2 in one place.
- Time-bomb tests. The parameterized cases use real now(). 1/15/35 → 1935 (past) only holds while 2035 is in the future; it flips after Jan 2035. The RELATIVE_BASE test is the robust pattern — the others should follow it.

Recommendation

The intent and core logic are right and worth merging, but I wouldn't merge as-is: bugs #1 and #2 are crashes the old code didn't have. I'd want naive/aware normalization before the comparison, a leap-year-safe century shift (reuse _get_correct_leap_year), and the parameterized tests pinned to RELATIVE_BASE.