toolkit: TimeSeriesChart can pin its time axis to a full window - #457
Merged
Conversation
Points' own first/last At auto-derives the displayed span today, which means a chart backed by day-old history renders as a one-day chart, not a mostly-empty week — wrong for a caller that wants to always show a full period (a rolling 7-day view, say) from the very first render, not one that only ever covers however much data happens to have accumulated. TimeMin/TimeMax (ignored unless TimeMax > TimeMin) let a caller pin the axis explicitly, mirroring Min/Max's own existing "always taken as given, never auto-derived" convention for the value axis. The curve itself is unaffected — still nothing drawn with fewer than two points — but the axis scaffolding (vertical gridlines, end labels) now renders against the full pinned window even with zero or one real point yet. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
1 task
tannevaled
added a commit
to go-aiquota/tray
that referenced
this pull request
Sep 6, 2026
…#15) Live user feedback: the weekly panel only shows ~21 hours since that's all the app has been running — it should show a full 7 days from the very first render, growing fuller as real data accumulates, not a window that only ever covers whatever history happens to exist yet. Picks up go-widgets/toolkit#457 (TimeMin/TimeMax) and pins each chart's displayed time axis to [now - SeriesWindowDuration, now] — the session panel always shows its own 5h window, weekly always shows its own 7 days, recomputed on every refresh so both windows slide forward with real time. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
TimeSeriesChart's time axis auto-derives fromPoints[0].At/the last point'sAt— fine once a series has real history, wrong for a fresh chart backed by only a few hours of data that's meant to always represent a full period (a rolling 7-day view, say). Live user feedback: a weekly usage chart backed by ~21 hours of real history rendered as a ~21-hour chart, not a mostly-empty week.TimeMin, TimeMax int64(ignored unlessTimeMax > TimeMin) to pin the displayed span explicitly — mirroringMin/Max's own existing "always taken as given, never auto-derived" convention for the value axis, just applied to the time axis too.Test plan
go build ./...,go vet ./...,gofmt -l .cleango test ./...green across the whole repo, zero regressions — every prior TimeSeriesChart test (including anti-aliasing/Threshold/FollowPeak/Series-binding from toolkit: a chart's series can be bound #453-456) passes unchanged🤖 Generated with Claude Code