Fix Date Picker always inserting 12:00 instead of the picked date - #48
Merged
Conversation
Reported: picking a date via the calendar grid or a quick-select
button always inserted 12:00 as the time. Root cause: getDateStr()
reformatted the already-resolved this.selectedDate down to a bare
"YYYY-MM-DD" string and fed that back into plugin.parseDate() to
build the output -- discarding whatever time this.selectedDate
actually had, and chrono-node defaults a date given with no time
component to noon. Verified directly: parsing a bare "2026-07-20"
produces a moment at 2026-07-20T12:00:00.
Fix: only round-trip through the NLP parser when the user actually
typed free-form text in the manual field (which may legitimately
include a time, e.g. "today at 3pm"); for calendar/quick-button
selections, format this.selectedDate directly -- it's already a
fully-resolved moment with nothing left to parse.
Also fixed a related inconsistency while auditing the rest of the
modal: quick-select buttons (Today/Tomorrow/Next week/...) built their
moments with plain moment()/moment().add(...), carrying the real
current wall-clock time instead of a clean date -- clicking "Tomorrow"
at 14:32 selected tomorrow at 14:32. Normalized to .startOf("day"),
matching the calendar grid (already midnight-based) and the modal's
initial selectedDate and Home-key shortcut.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011AnUmNKkH1y4ZAEPKF1WwQ
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request fixes a bug in the Date Picker where selecting a date via the calendar grid or quick-select buttons incorrectly defaulted the time to 12:00 or carried the current wall-clock time. This is resolved by normalizing selected dates to midnight and avoiding redundant round-trips through the NLP parser unless manual text is typed. The reviewer suggested optimizing performance by caching the parsed Moment object to avoid redundant NLP parsing calls on every keystroke in the manual input field.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Typing in the Date Picker's manual field invoked plugin.parseDate() 2-3 times per keystroke (once in onChange to validate, again via updateSelectedDate -> updatePreview -> getDateStr, and once more via onChange's own trailing updatePreview() call). Caches the parsed moment for the current input text, shared between onChange and getDateStr(), and removes the now-redundant explicit updatePreview() call after a successful parse (updateSelectedDate() already runs it). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011AnUmNKkH1y4ZAEPKF1WwQ
The Date Picker previously always carried some time value alongside the picked date -- the real current wall-clock time for calendar/ quick-button selections (fixed to always be midnight in the prior commit), or whatever chrono-node inferred from typed free-form text. There was no way to control or clear it, since nothing in the modal's UI exposes a time-of-day control. Rather than adding a settings menu to make the time optional, simplify: this is a date picker, not a time picker, so it never surfaces a time, full stop -- including when the manual input field is used to type a phrase that includes one (e.g. "today at 3pm"). Also removed the unused modalToggleTime setting and switched the default/placeholder format from "YYYY-MM-DD HH:mm" to "YYYY-MM-DD". Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011AnUmNKkH1y4ZAEPKF1WwQ
Merged
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
Reported by the maintainer: picking a date via the Date Picker's calendar grid or a quick-select button (Today/Tomorrow/Next week/...) always inserted
12:00as the time, regardless of what was actually selected.Root cause
getDateStr()reformatted the already-resolvedthis.selectedDatedown to a bare"YYYY-MM-DD"string and fed that back intoplugin.parseDate()to build the preview/output — discarding whatever timethis.selectedDateactually had. chrono-node defaults a date given with no time component to noon. Verified directly: parsing a bare"2026-07-20"produces a moment at2026-07-20T12:00:00.Fix
Only round-trip through the NLP parser when the user actually typed free-form text in the manual field (which may legitimately include a time, e.g.
"today at 3pm"). For calendar/quick-button selections, formatthis.selectedDatedirectly — it's already a fully-resolved moment with nothing left to parse.While auditing the rest of the modal (as requested), also found and fixed a related inconsistency: quick-select buttons built their moments with plain
moment()/moment().add(...), carrying the real current wall-clock time instead of a clean date — clicking "Tomorrow" at 14:32 selected tomorrow at 14:32. Normalized to.startOf("day"), matching the calendar grid (already midnight-based), the modal's initialselectedDate, and theHome-key shortcut.Verification
plugin.parseDate/shows noon, quick-button pick same, typed free-form text (with a real time) still parses correctly, andselectedDatedefaults to midnight on construction.getDateStr()to the old re-parse logic, reran, both failed exactly reproducing the reported "12:00 no matter what" behavior, then passed again after restoring the fix.npx tsc --noEmit,npx eslint, andnpm run buildall clean.Generated by Claude Code