Skip to content

fix: stop treating daily dates on the 1st as month-only labels - #71

Merged
Carl723000 merged 2 commits into
ClaudeCodeUsage:mainfrom
YuboZhang:main
Jul 18, 2026
Merged

fix: stop treating daily dates on the 1st as month-only labels#71
Carl723000 merged 2 commits into
ClaudeCodeUsage:mainfrom
YuboZhang:main

Conversation

@YuboZhang

@YuboZhang YuboZhang commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes a date formatting bug in the This Month tab's daily breakdown table: days that fall on the 1st of the month (e.g. 2026-07-01) were displayed as month names ("July 2026") instead of specific dates ("2026/7/1"). Both formatDate and getShortDate used dateString.endsWith('-01') as a heuristic to distinguish monthly aggregate labels from daily dates, which breaks for any daily data point on the 1st. The fix replaces the heuristic with an explicit monthly parameter so the caller indicates the intended context.

Linked issues

None

Type of change

  • Bug fix (non-breaking) → fix (patch)
  • New feature (non-breaking) → feature (minor)
  • Breaking change (existing behaviour differs afterwards) → breaking (major)
  • Documentation / CI / chore → docs / ci / chore (patch)

How was this tested?

  1. Built a .vsix (npx @vscode/vsce package) and installed it in VS Code
  2. Verified that dates on the 1st of the month in the This Month tab now show as specific dates (e.g. 2026/7/1)
  3. Confirmed the All Time tab's monthly aggregates still display month names (e.g. "July 2026") — no regression
  4. npm run compile is clean

Checklist

  • npm run compile is clean
  • User-facing strings go through I18n with all six languages filled — N/A, only date formatting logic changed
  • CHANGELOG.md updated (user-visible changes)
  • README.md updated if behaviour/settings changed — N/A
  • New settings default to existing behaviour (opt-in) — N/A
  • No new runtime dependencies

@YuboZhang @claude
fix: stop treating daily dates on the 1st as month-only labels
9d8cb7b 
The heuristic dateString.endsWith('-01') was used in both formatDate
and getShortDate to decide whether a date is a monthly aggregate label
(always YYYY-MM-01) or an actual daily date. This breaks when a daily
data point falls on the 1st of the month — it gets displayed as just
the month name instead of the specific date.

Replace the heuristic with an explicit 'monthly' parameter so
callers that render monthly aggregates pass true and daily-data
callers pass false (the default).

Co-Authored-By: Claude <noreply@anthropic.com>
@github-actions github-actions Bot added the fix Patch — bug fix label Jul 8, 2026
@YuboZhang @claude
fix: monthly date labels show previous month in negative-UTC timezones
735ab10 
formatDate uses new Date('YYYY-MM-DD') which interprets the string as
UTC midnight. For users in timezones west of UTC (Americas, Europe),
this rolls the date back by a day, causing monthly labels in the All
tab to show the previous month (e.g. 'May 2026' for June 2026 data).

Parse textually and build a Date via Date.UTC with an explicit
timeZone: 'UTC' in toLocaleDateString instead. The date keys from
dayKeyInZone / monthKeyInZone are already timezone-aware, so UTC
formatting preserves the correct display.

Co-Authored-By: Claude <noreply@anthropic.com>
@Carl723000

Carl723000 commented Jul 12, 2026

Copy link
Copy Markdown
Collaborator

Thanks @YuboZhang — clean refactor (explicit monthly param instead of the endsWith('-01') heuristic), and it correctly fixes daily points that land on the 1st.

One note so we don't accidentally consider #54 closed by this: formatDate's monthly branch still does new Date(dateString) (UTC midnight) + toLocaleDateString, so the All-time Monthly label is still a month behind in negative-UTC timezones. I've opened #72 with the complementary fix (textual parse + noon-UTC), which closes #54. Suggest merging this on its own merits; #54 is covered by #72. LGTM for the daily-label fix.

🤖 Generated with Claude Code

@YuboZhang

YuboZhang commented Jul 13, 2026

Copy link
Copy Markdown
Contributor Author

Yes， @Carl723000 I found and fixed the issue #54 too in this PR. If it has been fixed, you can close this PR. Thanks.

@Carl723000 Carl723000 mentioned this pull request Jul 18, 2026
Merged
8 tasks done
@Carl723000

Carl723000 commented Jul 18, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Correction: this PR has been reopened. Its implementation must enter main through the contributor's PR so GitHub and the release record preserve @YuboZhang's contribution. I will reconcile the complementary V2.2.1 changes around this PR instead of treating it as superseded.

🤖 Generated with OpenAI Codex

@Carl723000 Carl723000 closed this Jul 18, 2026
@Carl723000 Carl723000 reopened this Jul 18, 2026
@Carl723000
Carl723000 merged commit 845944b into ClaudeCodeUsage:main Jul 18, 2026
4 checks passed
@Carl723000 Carl723000 mentioned this pull request Jul 18, 2026
Merged
1 task done
Carl723000 added a commit to Carl723000/ClaudeCodeUsage that referenced this pull request Jul 18, 2026
@Carl723000
merge main after contributor PRs ClaudeCodeUsage#71 and ClaudeCodeUsa…
8f775ea 
…ge#72

Preserve the merged contributor fixes as the base while retaining the reviewed V2.2.1 testability and automation-hardening follow-ups.\n\n---\n🤖 Generated with [OpenAI Codex](https://developers.openai.com/codex/)
@Carl723000 Carl723000 mentioned this pull request Jul 18, 2026
Closed
3 tasks done
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Carl723000 Carl723000 Awaiting requested review from Carl723000 Carl723000 is a code owner
@jack21 jack21 Awaiting requested review from jack21 jack21 is a code owner

Assignees

No one assigned

Labels

fix Patch — bug fix

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@YuboZhang @Carl723000