Fix #274: Correct timezone parsing in dashboard statistics chart#275
Fix #274: Correct timezone parsing in dashboard statistics chart#275
Conversation
The dashboard chart was incorrectly parsing date strings using `new Date()`, which treats date-only strings (e.g., "2025-12-06") as UTC midnight instead of local midnight. This caused dates to display incorrectly for users in non-UTC timezones. Added `parseLocalDate` helper that manually parses date strings as local time, fixing the timezone offset issue in both the chart axis labels and tooltip displays. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Summary of ChangesHello @ding113, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 此拉取请求旨在解决仪表盘统计图表中存在的时区显示错误。通过引入一个自定义的日期解析函数 Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![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 correctly addresses a timezone parsing issue where date-only strings were being interpreted as UTC. The introduction of the parseLocalDate helper function to explicitly handle date strings as local time is the right approach. The changes in formatDate and formatTooltipDate correctly apply this new helper.
My review includes a suggestion to make the new parseLocalDate function more robust by using a regular expression for parsing. This will make it less prone to errors with malformed or unexpected date string formats. Overall, this is a good fix for the reported bug.
| function parseLocalDate(dateStr: string): Date { | ||
| const normalized = dateStr.replace("T", " ").split(" "); | ||
| const [year, month, day] = normalized[0].split("-").map(Number); | ||
| const timePart = normalized[1]?.split(":").map(Number) || [0, 0, 0]; | ||
| return new Date(year, month - 1, day, timePart[0] || 0, timePart[1] || 0, timePart[2] || 0); | ||
| } |
There was a problem hiding this comment.
The current implementation for parseLocalDate is a good solution for the timezone problem. However, it relies on split which can be fragile if the date string format varies slightly or is malformed.
I suggest using a regular expression to parse the date string, which is more robust and explicit about the expected format. This revised version ensures that only strings matching the YYYY-MM-DD format (with an optional time part) are parsed this way, falling back to the default new Date() constructor for any other format. This makes the function more predictable.
function parseLocalDate(dateStr: string): Date {
const match = dateStr.match(/^(\d{4})-(\d{2})-(\d{2})(?:[T ](\d{2}):(\d{2}):(\d{2}))?/);
if (!match) {
return new Date(dateStr);
}
const [, y, m, d, h, i, s] = match;
return new Date(Number(y), Number(m) - 1, Number(d), Number(h) || 0, Number(i) || 0, Number(s) || 0);
}
ding113
left a comment
ding113
left a comment
There was a problem hiding this comment.
Code Review Summary
No significant issues identified in this PR. The parseLocalDate helper function correctly addresses the UTC vs local time parsing issue by manually constructing Date objects from parsed components.
PR Size: XS
- Lines changed: 21 (18 additions, 3 deletions)
- Files changed: 1
Review Coverage
- Code quality and correctness - Clean
- Security (OWASP Top 10) - Clean
- PR size assessment - XS
- Dependency changes - N/A (no package changes)
- Documentation changes - N/A (no docs changes)
Automated review by Claude AI
ding113
left a comment
ding113
left a comment
There was a problem hiding this comment.
Code Review Summary
No significant issues identified in this PR. The parseLocalDate helper function correctly addresses the UTC vs local time parsing issue by manually constructing Date objects from parsed components.
PR Size: XS
- Lines changed: 21 (18 additions, 3 deletions)
- Files changed: 1
Review Coverage
- Code quality and correctness - Clean
- Security (OWASP Top 10) - Clean
- PR size assessment - XS
- Dependency changes - N/A (no package changes)
- Documentation changes - N/A (no docs changes)
Automated review by Claude AI
github-project-automation
bot
moved this from Backlog
to Done
in Claude Code Hub Roadmap
1 participant
Summary
Fixes the timezone display issue in the dashboard statistics chart reported in #274.
Root Cause
The
formatDateandformatTooltipDatefunctions inchart.tsxusednew Date(dateStr)to parse date strings. When the backend returns date-only strings like"2025-12-06", JavaScript'sDateconstructor interprets them as UTC midnight rather than local midnight. This causes a timezone offset when displaying dates to users in non-UTC timezones (e.g., UTC+8).Solution
Added a
parseLocalDatehelper function that manually parses date strings into local Date objects by extracting year, month, day, and time components. This ensures dates are interpreted as local time regardless of the input format.Changes
parseLocalDate()helper function that correctly parses date strings as local timeformatDate()to useparseLocalDate()instead ofnew Date()formatTooltipDate()to useparseLocalDate()instead ofnew Date()Test Plan
Closes #274
🤖 Generated with Claude Code