[pull] master from scrapinghub:master#95
Merged
Conversation
#1342) * fix: Apply PREFER_DATES_FROM logic to custom date formats Fixes #445 - settings.PREFER_DATES_FROM setting now correctly applies when date_formats are explicitly specified with 2-digit year formats (%y). Previously, when date_formats were provided, the parser would bypass the PREFER_DATES_FROM logic and directly use strptime(), causing ambiguous 2-digit years to be interpreted in the wrong century. Changes: - Enhanced parse_with_formats() to detect 2-digit year formats (%y) - Apply year adjustment logic based on PREFER_DATES_FROM setting - Added comprehensive test coverage for date_formats + PREFER_DATES_FROM Test results: - All 24,056 existing tests pass - Added 5 new test cases covering various scenarios * fix: respect PREFER_DATES_FROM and RELATIVE_BASE in date_formats path (closes #445) When date_formats is provided, parse_with_formats() bypassed the PREFER_DATES_FROM setting entirely, always returning future-century dates for 2-digit year formats (%y). Changes: - Apply PREFER_DATES_FROM logic in parse_with_formats() for 2-digit year formats: subtract 100 years when preference is 'past' and the parsed date is in the future; add 100 years when preference is 'future' and the parsed date is in the past - Respect settings.RELATIVE_BASE as the reference point (matching the NLP path in parser.py), falling back to datetime.now(tz=utc) when unset - Use == instead of 'in' for PREFER_DATES_FROM string comparisons - Use datetime.now(tz=timezone.utc) consistently, replacing datetime.today() Tests: - Add 5 parameterised cases covering past/future preference with 2-digit years, and 4-digit year isolation - Add dedicated test asserting RELATIVE_BASE is honoured * fix: respect PREFER_DATES_FROM and RELATIVE_BASE in date_formats path (closes #445) - Add _apply_century_preference() helper to date.py, mirroring the _get_correct_leap_year pattern from parser.py for consistency. - Helper shifts 2-digit year dates ±100 years based on PREFER_DATES_FROM; on ValueError (Feb 29 → non-leap year) it finds the nearest valid leap year in the preferred direction using get_next/previous_leap_year. - parse_with_formats now uses RELATIVE_BASE (falling back to UTC now) for both the missing-year branch and the 2-digit-year branch. - Fix tz-aware RELATIVE_BASE crash: now is normalised to naive before comparison, preventing TypeError between offset-naive and offset-aware datetimes. - Add 8 regression tests pinned to RELATIVE_BASE=datetime(2026, 1, 1) to avoid time-bomb failures.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )