Issue #388: fix: handle spaced date ranges and prevent endDate loss in parse_date_range
Recommended: merge #389
fix: handle spaced date ranges and prevent overwriting existing endDates in parse_date_range
How it breaks
The path is the model's reasoning. Each box is a citation checked against the code.
What's wrong
Both bugs are confirmed in transform.py. (1) In transform_work_experience, any startDate containing a month name is passed to parse_date_range, and the result is assigned to both start_date and end_date. The item's own endDate is only read in the else branch, so it is lost whenever the start date has a month.Show full explanation
For a single date like "Jan 2021", parse_date_range returns (start, None), so end_date becomes None. This differs from the report's wording: there is no literal `end_date = None`, and the overwrite comes from the tuple unpacking. (2) parse_date_range splits on spaces and only recognises a hyphen inside parts[0] ("Jan-Mar 2021"). For "Jan 2021 - Mar 2022" the parts are ["Jan","2021","-","Mar","2022"]. parts[0] has no hyphen, so the else branch runs. It builds "Jan" plus parts[-1] ("2022"), giving ("Jan 2022", None). The real start year and the end date are both discarded.How to reproduce
- From the repo root run: python3 -I -c "import transform as t; print(t.parse_date_range('Jan 2021 - Mar 2022'))". It prints ('Jan 2022', None), but ('Jan 2021', 'Mar 2022') is expected.
- Run: python3 -I -c "import transform as t; print(t.transform_work_experience([{'name':'X','startDate':'Jan 2021','endDate':'Dec 2022'}]))". The output has endDate None, but 'Dec 2022' is expected.
- Run: python3 -I -c "import transform as t; print(t.parse_date_range('Jan 2021'))". It prints ('Jan 2021', None), which confirms the single-date return value.
Evidence
Each citation was checked against the code at e0ece80.
Any month-bearing startDate overwrites end_date with the parser's second value, ignoring item['endDate'].
The item's real endDate is read only in the else branch, which is skipped when the startDate has a month name.
Splitting on spaces turns 'Jan 2021 - Mar 2022' into 5 parts, and the ' - ' separator is never handled.
Only a hyphen inside the first token counts as a range, so the spaced form never matches.
The else branch takes the first month 'Jan' and combines it with the last part, the end year.
The else branch always returns None as the end date, so both single dates and spaced ranges lose their end.
Pull requests
Verdicts are judged from the diff, not run. Merge status is a real git check against e0ece80.
It adds an early ' - ' split in parse_date_range that returns both full dates, and it adds the `if not end_date: end_date = item.get('endDate')` fallback in transform_work_experience, which covers both causes.
It falls back to item.get('endDate') when the parser returns no end, and the rewritten parse_date_range normalizes ' - ' so 'Jan 2021 - Mar 2022' returns ('Jan 2021','Mar 2022') while 'Jan-Mar 2021' and single dates still work.
1 PRs that don't fix itShow
It only removes the identity month_map, an unused parameter and a dead option, so the spaced-range parsing and the end_date overwrite in transform_work_experience behave exactly as before.
What this packet does not prove
- Citations are checked against the code. The explanation that links them, the order of the chain, and any claim about outside systems (APIs, libraries) are the model's reasoning and are not checked.
- PR verdicts are judged from the diff, not run. No PR was applied or tested.
- PRs were shortlisted because they change a cited line or mention the issue. A fix in another file, or a PR whose line numbers have drifted, is missed, so this is not proof that no other PR fixes it.