test(format): lock DATE+N offsets from issue 1704 - #1707
Conversation
Issue #1704 reported {{DATE:YYYY-MM-DD+3}} concatenating +3 and {{DATE+3}} left unparsed. The formatter already applies the offset (including case-insensitive date tokens). Assert the documented examples so concatenation cannot regress silently. Co-authored-by: Christian Bager Bach Houmann <[email protected]>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review. 📝 WalkthroughWalkthroughThe change adds tests for ChangesDATE offset validation
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change only strengthens automated coverage for existing date-offset formatting behavior and does not alter production code; no actionable merge-blocking risk remains after normal checks and review. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2 files. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
Deploying quickadd with
|
| Latest commit: |
91e70d1
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://a8814cbd.quickadd.pages.dev |
| Branch Preview URL: | https://cursor-issue-1704-date-offse.quickadd.pages.dev |
2 participants
Summary
Lock the documented
{{DATE+N}}/{{DATE:YYYY-MM-DD+N}}day-offset behavior so the concatenation and leftover-token symptoms from #1704 cannot regress silently.This does not change formatter production code. On current
master(QuickAdd 2.23.0), those tokens already resolve to a shifted date.Refs #1704 (not
Fixes) — the reported bug was not reproducible in this checkout, so the issue should stay open until a maintainer confirms with the reporter.Why
#1704 reports that, with a frozen "today" of
2026-08-26:{{DATE:YYYY-MM-DD}}and{{DATE}}work{{DATE:YYYY-MM-DD+3}}becomes2026-08-26+3instead of2026-08-29{{DATE+3}}is left unparsed|startof:/|endof:snap examples also failDATE_REGEX/DATE_REGEX_FORMATTEDalready split format from+N, andreplaceDateInStringappliesgetDate({ format, offset, snap }). The previous docs-examples suite only asserted that no{{...}}token remained, so2026-08-26+3would still have passed.Scope
{{date+3}}, since the regex is/i/) informatter-datesnap.test.tsagainst a frozen clock.{{DATE+7}}and{{DATE:YYYY-MM-DD+3}}render the shifted date informatSyntax.docs-examples.test.ts.src/production, docs, or bundle changes.Tradeoffs
Blast radius
Runtime: none. Tests only. Failure mode if the lock is wrong: CI red on a date-format change, not a user-facing change.
Testing / validation
pnpm run test— 4989 passed, 37 skippedpnpm run lint— clean2026-08-26 12:00:api.format():{{DATE+3}}→2026-08-29,{{DATE:YYYY-MM-DD+3}}→2026-08-29(not2026-08-26+3)executeChoicewith the issue's markdown created a note whose "buggy" section was2026-08-29/2026-08-29;|startof:weekresolved to2026-08-23Likely reporter mix-up, not a formatter defect: Obsidian core Templates
{{date:YYYY-MM-DD+3}}passesYYYY-MM-DD+3to Moment (literal+3) and does not parse{{DATE+3}}. Same two symptoms. QuickAdd only expands these tokens when it formats the string (Template / Capture / Macro /api.format()).Checklist
Summary by CodeRabbit
DATEday-offset formatting.