Root Cause
In render_session_detail (src/copilot_usage/render_detail.py), session_start is computed as:
session_start = (
ensure_aware(summary.start_time) if summary.start_time is not None
else (
ensure_aware(events[0].timestamp) if events and events[0].timestamp is not None
else datetime.now(tz=UTC)
)
)
```
When `summary.start_time is None` **and** `events[0].timestamp is None`, the fallback is `datetime.now(tz=UTC)`. If any later event in the list has a timestamp from the past, its delta is:
```
delta = ensure_aware(ev.timestamp) - datetime.now(tz=UTC) → negative
_format_relative_time computes max(int(delta.total_seconds()), 0), clamping all negative deltas to 0. Every event with a past timestamp therefore displays +0:00 instead of the actual relative offset from the earliest known event.
This is a silent data-loss bug — the timing column renders incorrect values with no error or warning.
Affected Code
src/copilot_usage/render_detail.py — the session_start ternary (currently only checks events[0])
src/copilot_usage/render_detail.py — _format_relative_time (correct, no change needed)
Reproduction Scenario
Session with:
summary.start_time = None
events[0].timestamp = None (e.g., a synthetic/placeholder event)
events[1].timestamp = <some past datetime>
events[2].timestamp = <some past datetime + 5 min>
Current behaviour: both events[1] and events[2] show +0:00 in the time column.
Expected behaviour: events[1] shows +0:00 (it anchors the view), events[2] shows +5:00.
Fix
Scan all events for the first non-None timestamp rather than only checking events[0]:
session_start = (
ensure_aware(summary.start_time)
if summary.start_time is not None
else next(
(ensure_aware(ev.timestamp) for ev in events if ev.timestamp is not None),
datetime.now(tz=UTC),
)
)
Testing Requirement
Add a regression test to tests/copilot_usage/test_render_detail.py covering the mixed-timestamp case:
start_time=None
events[0].timestamp = None
events[1].timestamp = T (a fixed past datetime)
events[2].timestamp = T + 5 minutes
Assert that the rendered output for events[2] contains +5:00 (not +0:00). This is distinct from the existing TestRenderSessionDetailBothTimestampsNone test which uses a single event with no timestamp and only asserts the render does not raise.
Generated by Code Health Analysis · ● 4.9M · ◷
Root Cause
In
render_session_detail(src/copilot_usage/render_detail.py),session_startis computed as:_format_relative_timecomputesmax(int(delta.total_seconds()), 0), clamping all negative deltas to0. Every event with a past timestamp therefore displays+0:00instead of the actual relative offset from the earliest known event.This is a silent data-loss bug — the timing column renders incorrect values with no error or warning.
Affected Code
src/copilot_usage/render_detail.py— thesession_startternary (currently only checksevents[0])src/copilot_usage/render_detail.py—_format_relative_time(correct, no change needed)Reproduction Scenario
Session with:
summary.start_time = Noneevents[0].timestamp = None(e.g., a synthetic/placeholder event)events[1].timestamp = <some past datetime>events[2].timestamp = <some past datetime + 5 min>Current behaviour: both events[1] and events[2] show
+0:00in the time column.Expected behaviour: events[1] shows
+0:00(it anchors the view), events[2] shows+5:00.Fix
Scan all events for the first non-None timestamp rather than only checking
events[0]:Testing Requirement
Add a regression test to
tests/copilot_usage/test_render_detail.pycovering the mixed-timestamp case:start_time=Noneevents[0].timestamp = Noneevents[1].timestamp = T(a fixed past datetime)events[2].timestamp = T + 5 minutesAssert that the rendered output for events[2] contains
+5:00(not+0:00). This is distinct from the existingTestRenderSessionDetailBothTimestampsNonetest which uses a single event with no timestamp and only asserts the render does not raise.