Fix launchDesk#4
Open
Dilshan Madusanka (madudilshan47-dot) wants to merge 11 commits into
Open
Conversation
📝 WalkthroughWalkthroughThis PR corrects multiple bugs across the checklist application: storage key consistency, form validation, search/filter matching, item deletion, status updates, CSS rendering, metrics calculation, demo data loading, and CSV export field names. ChangesChecklist Application Bug Fixes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@js/app.js`:
- Around line 240-243: The day-difference calculation used for the dueSoon
bucket is off-by-one because daysUntil compares a parsed date (UTC midnight)
with new Date() (local time); update the daysUntil implementation so it
normalizes both the target date and "today" to local midnight (e.g.,
setHours(0,0,0,0) or equivalent) before computing the difference, then keep
using that corrected daysUntil when computing dueSoon in the expression that
filters checks.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
Comment on lines
+240
to
+243
| const dueSoon = checks.filter((check) => { | ||
| const days = daysUntil(check.dueDate); | ||
| return days >= 0 && days <= 7; | ||
| }).length; |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In ECMAScript, does new Date("2026-05-10")parse as UTC or local time, and what is the recommended way to avoid off-by-one day errors when computing day differences againstnew Date()?
💡 Result:
new Date("2026-05-10")is parsed as UTC midnight (2026-05-10T00:00:00Z), not local time. [1] So the Date object represents an instant at the start of the UTC day; when you display it using local-time getters/formatters (e.g.,toString(),getFullYear(), etc.), it may appear as the previous day in time zones west of UTC (off-by-one in the display layer). 2) Recommended way to avoid off-by-one day errors when computing day differences vsnew Date()For “calendar day” differences, don’t subtract raw timestamps coming from mixed origins/normalizations. Instead, normalize both sides to a consistent day boundary in the domain you care about (UTC for global/backend logic, or a specific IANA time zone via a library/Temporal). If you want UTC-based day differences using ISO date-only strings, parse them as UTC and then compute using UTC midnight: const start = new Date('2026-05-10T00:00:00Z'); const end = new Date; // Normalize end to UTC midnight too end.setUTCHours(0, 0, 0, 0); const msPerDay = 24 * 60 * 60 * 1000; const diffDays = Math.round((end - start) / msPerDay); Why this helps:Datemath is based on instants (timestamps), while “day differences” are usually about calendar days; UTC avoids DST-length day problems because UTC days are always 86,400,000 ms, and normalization prevents partial-day values from producing 0.99/1.01 day rounding errors. [2][3] If you instead need “local calendar day” differences, normalize both dates using local midnight (viasetHours(0,0,0,0)), or better, use an explicit time zone library rather than relying on environment locale/timezone rules. Sources: [1] MDN Date page explains: when timezone offset is absent, date-only forms are interpreted as a UTC time (with a historical spec compatibility note). [3] ECMAScript spec defines time values relative to UTC days and 86,400,000 ms per day boundaries. [2] Synyx article explains DST/day-length issues and that UTC avoids those problems for “how many days” calculations.
Citations:
- 1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date
- 2: https://synyx.de/blog/properly-calculating-time-differences-in-javascript
- 3: https://tc39.es/ecma262/multipage/numbers-and-dates.html
🏁 Script executed:
git ls-files js/app.jsRepository: codezelaca/fs-se-debugging-bugs
Length of output: 85
🏁 Script executed:
if [ -f js/app.js ]; then wc -l js/app.js; fiRepository: codezelaca/fs-se-debugging-bugs
Length of output: 89
🏁 Script executed:
if [ -f js/app.js ]; then sed -n '235,250p' js/app.js; fiRepository: codezelaca/fs-se-debugging-bugs
Length of output: 701
🏁 Script executed:
rg "function daysUntil|const daysUntil" js/app.js -A 6Repository: codezelaca/fs-se-debugging-bugs
Length of output: 276
Normalize day math before dueSoon bucketing.
The daysUntil() function compares new Date(dateValue) (which parses ISO strings like "2026-05-10" as UTC midnight) against new Date() (which uses local time). This timezone mismatch causes incorrect day-difference calculations, producing off-by-one counts near the 0 and 7-day boundaries depending on the local timezone and time of day.
Normalize both dates to local midnight before computing the difference:
Suggested fix
function daysUntil(dateValue) {
- const today = new Date();
- const target = new Date(dateValue);
- const difference = target.getTime() - today.getTime();
- return Math.ceil(difference / 86400000);
+ if (!dateValue) return Number.POSITIVE_INFINITY;
+
+ const now = new Date();
+ const today = new Date(now.getFullYear(), now.getMonth(), now.getDate());
+
+ const [year, month, day] = String(dateValue).split("-").map(Number);
+ const target = new Date(year, month - 1, day);
+
+ return Math.floor((target.getTime() - today.getTime()) / 86400000);
}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@js/app.js` around lines 240 - 243, The day-difference calculation used for
the dueSoon bucket is off-by-one because daysUntil compares a parsed date (UTC
midnight) with new Date() (local time); update the daysUntil implementation so
it normalizes both the target date and "today" to local midnight (e.g.,
setHours(0,0,0,0) or equivalent) before computing the difference, then keep
using that corrected daysUntil when computing dueSoon in the expression that
filters checks.
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
1 participant
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 by CodeRabbit