feat: show billing reset times in the user's timezone#5
Conversation
|
Warning Review limit reached
Next review available in: 49 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughBilling reset timestamps now use the runtime’s local timezone and include timezone details. Status tests avoid fixed timezone assumptions, and the quota documentation describes the updated output format. ChangesLocal billing timezone
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 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 |
Greptile SummaryThis PR shows Grok CLI billing reset times in the local system timezone. The main changes are:
Confidence Score: 4/5The production formatter looks safe, but the changed tests need cleanup around reset-time coverage.
tests/provider/register.test.ts Important Files Changed
Reviews (1): Last reviewed commit: "feat: show usage reset in local timezone" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| expect(status).toContain('1% used'); | ||
| const localFormatter = new Intl.DateTimeFormat(undefined, { timeZoneName: 'short' }); | ||
| expect(status).toContain( | ||
| localFormatter.formatToParts(new Date()).find((part) => part.type === 'timeZoneName')?.value, |
There was a problem hiding this comment.
This expected timezone name comes from new Date(), but the command output formats the mocked July 2026 reset timestamps. In DST-observing zones, today's abbreviation can differ from July's abbreviation, so the test can fail even when the reset time is formatted correctly.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| const status = String(notify.mock.calls.at(-1)?.[0]); | ||
| expect(status).toContain('172 / 4,000 used 4%'); | ||
| expect(status).toContain('3,828 credits'); |
There was a problem hiding this comment.
This test still uses a monthly billing fixture with billingPeriodEnd, but it no longer checks that the Reset line is present or formatted. A regression that drops the reset time while keeping credits and remaining credits would pass, even though /grok-cli-usage is documented to print the reset time.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
tests/provider/register.test.ts (1)
246-250: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAvoid duplicating formatter logic in tests.
The test creates a new
Intl.DateTimeFormat(undefined, { timeZoneName: 'short' })to compute expected values, duplicating the formatter configuration frombilling.ts. If the implementation changes its formatter options (e.g.,timeZoneName: 'long'), this test would still pass using its own parallel formatter, missing the regression.Consider exporting
LOCAL_TIME_ZONEfrombilling.tsand importing it here to assert against the actual implementation value. As per coding guidelines, "do not duplicate logic into tests."♻️ Suggested refactor
In
src/provider/billing.ts, export the constant:-const LOCAL_TIME_ZONE = RESET_FORMATTER.resolvedOptions().timeZone; +export const LOCAL_TIME_ZONE = RESET_FORMATTER.resolvedOptions().timeZone;Then in the test, import and use it directly:
+import { LOCAL_TIME_ZONE } from '../../src/provider/billing'; + // ... - const localFormatter = new Intl.DateTimeFormat(undefined, { timeZoneName: 'short' }); - expect(status).toContain( - localFormatter.formatToParts(new Date()).find((part) => part.type === 'timeZoneName')?.value, - ); - expect(status).toContain(localFormatter.resolvedOptions().timeZone); + expect(status).toContain(LOCAL_TIME_ZONE);For the
timeZoneNameassertion, consider a regex pattern (e.g.,/GMT[+-]\d+|UTC|[A-Z]{3,4}/) or export the formatter itself frombilling.tsto avoid parallel construction.🤖 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 `@tests/provider/register.test.ts` around lines 246 - 250, Export the implementation’s LOCAL_TIME_ZONE value from billing.ts and import it in the test instead of recreating the formatter configuration. Update the assertions around the local time-zone name to avoid duplicating Intl.DateTimeFormat options, using an implementation-derived value or an appropriate pattern while still asserting the status contains the exported LOCAL_TIME_ZONE.Source: Coding guidelines
🤖 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.
Nitpick comments:
In `@tests/provider/register.test.ts`:
- Around line 246-250: Export the implementation’s LOCAL_TIME_ZONE value from
billing.ts and import it in the test instead of recreating the formatter
configuration. Update the assertions around the local time-zone name to avoid
duplicating Intl.DateTimeFormat options, using an implementation-derived value
or an appropriate pattern while still asserting the status contains the exported
LOCAL_TIME_ZONE.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 243cac1e-6165-42ce-b167-ec9059248369
📒 Files selected for processing (3)
README.mdsrc/provider/billing.tstests/provider/register.test.ts
|
Thanks for the contribution! |
2 participants
Summary
Display Grok CLI billing reset times in the local system timezone, including both the short offset/abbreviation and IANA timezone identifier (for example,
Jul 11, 13:01 GMT+7 Asia/Bangkok). This makes it easier for users to see exactly when their quota resets without converting from Pacific Time.Testing
bun run checkGenerated with pi using GPT-5.6, as noted in #3.
Summary by CodeRabbit
Bug Fixes
Documentation