A relative range like last 7 days rolls forward each visit; an absolute range stays pinned to fixed dates

What it is

A relative range ("last 7 days") anchors to the current moment and rolls forward each time the dashboard opens, pointing at a different calendar window; an absolute range ("2024-01-15 to 2024-01-20") is pinned to the calendar and always shows the same segment regardless of when it is opened. The difference is not notation but semantic commitment: relative promises "always show me the latest window of this length," absolute promises "always show me this same slice of history." Confusing the two commitments means a dashboard's readers see different data on repeat visits while believing they are looking at the same thing.

Why it happens

The suitability gap stems from a difference in viewing motivation. Relative ranges serve continuous monitoring: the user opens the dashboard every morning wanting "how are we doing versus yesterday/last week," and the window must roll for that question to make sense—a pinned absolute window becomes historical review on day two, no longer an operational signal. Absolute ranges serve post-hoc analysis and incident review: the user investigating "how did the metric move around last Friday's outage" needs the window nailed to the event date; otherwise the analysis anchor drifts on every refresh. The design implication is that both modes must coexist within one control, and the active mode's semantics must be visible—the user should be able to tell at a glance whether "last 7 days" is a rolling window or a selection that has been frozen into specific dates.

Where it stops holding

Converting between relative and absolute is lossy: once "last 7 days" is frozen into concrete dates and then reverted, the original rolling semantics are gone. Timezone is another boundary: a relative range like "today" points at different calendar windows in different time zones, so when a cross-timezone team shares a dashboard, A's "today" and B's "today" may be two different windows. For caching and precomputation systems, absolute-range queries can be cached precisely, while relative-range queries invalidate over time—this affects which mode is backend-feasible.

Applying it

• Offer both relative presets and absolute date selection in one control; make the active mode visible on the control itself.
• When a user pins a relative range into absolute dates, label it "pinned" next to the control and provide a way back to rolling.
• On cross-timezone dashboards, display the data timezone beside the control and annotate relative presets like "today" with their anchoring timezone.
• Verification: have a colleague open your saved dashboard link the next day and confirm the window matches what you expected; a mismatch means the mode semantics are unclear.

Related

• Same group: U7.06.1 The default time range determines the conclusion most users will see · U7.06.2 Preset ranges should cover common cycles and allow custom input · U7.06.4 Comparison baselines must update in sync when the time range changes · U7.06.5 The active time range must be visible alongside the chart
• Nearby: U10.02.1 The chosen time window decides the trend's direction · U7.05.5 The comparison period's statistical scope must match the current period's
• Search terms: relative time range · absolute time range · rolling window