irisandClaude Opus 5
4edc96de09
The five-hour window's reset time is absent between blocks, because the window is anchored to the block it started in and there is nothing to reset until one is running. Measured against a live response: the reset came back as exactly five hours after work resumed, and the weekly windows in the same response carried the identical microsecond, so both are computed from one now() at request time. The weeklies always have a reset because a week is always running -- which is why only the five-hour row looked wrong. `remainingUntil` returned null for that and for a timestamp it could not parse, so the session bar announced "reset time unknown" about a machine behaving perfectly, on the one row somebody reads before starting something big. The usage dialog, looking at the same field, drew nothing at all and printed a raw ISO string when a parse did fail. One missing value, two rules, and neither of them right. `WindowEnd` names the three answers and both callers go through it. A window that is not running shows its percentage and no countdown, in the bar as well as the dialog; an unreadable timestamp says so in words rather than showing itself. Looked at both on the emulator, the second by making the server drop the field: 15% with "4h 43m left" when a block is running, "13%" alone when none is, and the dialog's five-hour row with no reset line beside weeklies that have one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>