Repository navigation
fix(core,ai,tui,cli): calendar-check non-ISO date strings in all six date parsers (#798) - #801
Conversation
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 19 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
The following comment was made by an LLM, it may be inaccurate: |
|
Hey! Your PR title Please update it to start with one of:
Where See CONTRIBUTING.md for details. |
|
This PR doesn't fully meet our contributing guidelines and PR template. What needs to be fixed:
Please edit this PR description to address the above within 72 hours, or it will be automatically closed. If you believe this was flagged incorrectly, please let a maintainer know. |
Closes #798
The calendar check in all six copies of the checked date parser only round-tripped an ISO
YYYY-MM-DDprefix and returned the bareDate.parseresult for every other shape — so"Feb 30 2026"rolled to Mar 2 and passed, reopening the Feb-30 class for every consumer routed through these parsers (#785/#779/#717).Fix, applied identically in all six copies (
coreForm.isDateTime,coreModelRouteLimits.parseAbsoluteTime,aiexecutor parseHttpDate,aiReplicate parseCompletedAt,tuivalidDateTime,clivalidDateTime):namedDatePartshelper extracts calendar components from non-ISO forms whose parts are named or ordered unambiguously —"Feb 30 2026","Feb 30, 2026","30 Feb 2026","2026/02/30"— and the existing round-trip probe now runs on those components as well as ISO ones.!isoreturn, so"Feb 30 2026 24:00"passed on both counts).02/03/2026) and shapes without named components keep the documented lenient behaviour; valid non-ISO forms ("Jan 5 2026", IMF-fixdate HTTP-dates) parse exactly as today.Tests (laptop, packages/core: 45/45 across the two files, including 2 new tests):
parseAbsoluteTimerejects all named overflow spellings + non-ISO hour-24 and keeps valid controls exact;Form.validateAnswerrejects the same spellings fordate-timefields and keeps valid non-ISO answers. The ai/tui/cli copies are byte-identical logic and are covered by CI for their packages.Queue task 2954 (repo-health-opencode-pilot).
Need help on this PR? Tag
@codesmith-botwith what you need.