Skip to content

fix(utils): detect date precision without counting dashes - #4007

Open
LemonCondor wants to merge 1 commit into
opendatateam:mainfrom
LemonCondor:fix-daterange-undashed
Open

LemonCondor wants to merge 1 commit into
opendatateam:mainfrom
LemonCondor:fix-daterange-undashed

Conversation

@LemonCondor

Copy link
Copy Markdown

Fix #4006.

daterange_start / daterange_end guessed the precision of a date (full date, year/month, year) by counting - characters, so values such as 2020/05/17, 20200517 or May 2020 — which dateutil parses correctly — were turned into the whole year 2020. These functions parse the free-text temporal_start / temporal_end extras of the CKAN harvester.

The new _parse_date_precision helper parses the value against two different default dates (January 1st and March 3rd of the current year, both in 31-day months): a month or day that is identical in both results was given explicitly. Dashed values keep exactly the same result, and the current year is still used when a value has no year, as before.

Tests: two new cases in DateRangeTest (full dates and year/month without dashes) fail before the change and pass after; pytest udata/tests/test_utils.py → 54 passed. ruff format --check passes; ruff check reports the same pre-existing warnings as on main for these two files.

🤖 Generated with Claude Code

…tateam#4006)

daterange_start and daterange_end treated any value without two dashes as
a year/month or a year only, so "2020/05/17", "20200517" or "May 2020"
became the whole of 2020. Find which parts were given by parsing the
value against two different default dates instead.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Temporal coverage dates without dashes are parsed as a whole year

1 participant