Roll Claude reset date forward across the year boundary#1947
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 6, 2026, 11:16 AM ET / 15:16 UTC. Summary Reproducibility: yes. from source inspection: current main parses yearless Claude date+time reset strings with the current year and returns them directly, so a Dec 31 now with a Jan 2 reset resolves into the past. Review metrics: 2 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Merge the narrow parser fix after required CI completes, keeping Claude reset parsing aligned with the existing Codex year-roll-forward behavior. Do we have a high-confidence way to reproduce the issue? Yes, from source inspection: current main parses yearless Claude date+time reset strings with the current year and returns them directly, so a Dec 31 now with a Jan 2 reset resolves into the past. Is this the best way to solve the issue? Yes, the PR is the narrowest maintainable fix I found: it reuses the existing roll-forward pattern already present in the time-only Claude branches and sibling Codex parser. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against b00797537dbf. Label changesLabel changes:
Label justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (1 earlier review cycle)
|
clawsweeper
Bot
added
rating: 🦪 silver shellfish
ClaudeStatusProbe.parseResetDate handled its two date+time branches
("MMM d, h:mma" etc.) by returning the parsed date as-is. Those formats
carry no year, so DateFormatter.defaultDate = now fills in the current
year. When the reset month/day is earlier in the calendar than now (a
"Jan 2" reset read on Dec 31), the result lands ~a year in the past.
A past resetsAt makes resetCountdownDescription clamp to "now"/"0h" and
widget "is active" checks treat the window as already expired, so the UI
shows the quota as reset hours before it actually is.
The time-only branches already roll forward (by a day), and the sibling
CodexStatusProbe already guards this exact case with bumpYearIfNeeded.
Apply the same guard to Claude's date+time branches.
Add a regression test that crosses the year boundary (now = Dec 31,
reset = "Jan 2, 3:00am"): it must resolve to next year and be in the
future.
steipete
force-pushed
the
fix/claude-reset-year-boundary
branch
from
660ebee to
85183ac
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 85183acd38
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if date >= now { return date } | ||
| return calendar.date(byAdding: .year, value: 1, to: date) |
There was a problem hiding this comment.
When the status probe crosses a reset boundary, this now treats any parsed date that is even seconds in the past as the same month/day next year. fetch() captures /usage first and only later parses the reset strings after the optional /status probe, so a weekly line like Resets Jul 6, 3:00pm captured just before 3:00 but parsed just after 3:00 becomes July 6 of the following year instead of a stale/expired reset. That leaves menus/countdowns with a reset hundreds of days out; please restrict the year bump to plausible Dec→Jan wraparound cases, such as when the bumped date is within the Claude reset window.
Useful? React with 👍 / 👎.
|
Maintainer verification on exact head
The black-box validation confirms the reset remains future-facing and yields |
2 participants
Summary
User-visible effect
On December 31, a Claude reset such as
Jan 2, 3:15amnow remains an upcoming reset. Previously it parsed as January of the current year, causing countdown surfaces to shownowand active-window checks to treat the quota as expired.Verification
make check: passed.make test: all 48 shards passed.