Summary
When running hermes-telemetry stats <subcmd> --from <iso> without a matching --to, the date-range label in the header is rendered as "X to X" and loses any time-of-day information from --from, even though the underlying query is doing the right thing.
This is purely a cosmetic / UX bug. The data returned is correct.
Repro
On a VPS that received API calls earlier in the day (before noon UTC) and none since:
$ hermes-telemetry stats models --from 2026-06-16T12:00:00Z
No API calls recorded in 2026-06-16 to 2026-06-16.
$ hermes-telemetry stats models --from 2026-06-16
hermes-telemetry — models (2026-06-16 to 2026-06-16)
============================================================================================================
Provider Model Calls Real Est Cost Notes
----------------------------------------------------------------------------------------------------------
nous nvidia/nemotron-3-ultra:free 153 153 0 $0.000000 subscription/free-tier
nous deepseek/deepseek-v4-pro-20260423 81 81 0 $0.617171
...
Both labels read "2026-06-16 to 2026-06-16", so the second call looks like an empty/inverted range even though the data is just genuinely empty (no API calls between 12:00 UTC and now).
Root cause
Two contributing pieces in PR #35:
-
telemetry_cli._resolve_date_range (telemetry_cli.py:169-178) auto-fills date_to = datetime.now(timezone.utc).isoformat() whenever the user passes only --from. The DB layer doesn't need this — with the datetime('now') upper-bound fix already in this branch, date_to=None works correctly as "no upper bound" — so the auto-fill is purely cosmetic plumbing into the label.
-
stats._date_range_label (stats.py:58-65) slices both ISO timestamps to [:10], stripping the time-of-day. Combined with (1), both ends collapse to today's date when --from is timestamped, producing "2026-06-16 to 2026-06-16".
Expected behaviour
--from 2026-06-16T12:00:00Z (no --to) → label "since 2026-06-16T12:00:00".--from 2026-06-16 (no --to) → label "since 2026-06-16".--from 2026-06-10 --to 2026-06-15 → label "2026-06-10 to 2026-06-15" (unchanged).- The matching
/stats slash command (in-chat) should behave the same way once the change lands.
Proposed fix
Two small changes:
- In
telemetry_cli._resolve_date_range, return (args.date_from, args.date_to) verbatim — don't synthesize date_to.
- In
stats._date_range_label, strip the +00:00 / Z suffix and drop the time portion only when it is exactly T00:00:00 (otherwise keep T12:00:00, etc., so the time slice is visible). Trim microseconds when present.
Add regression tests:
--from <ts> (no --to) renders "since <ts>", not "X to X".- A timestamped
--from keeps the time in the label.
Severity
Minor. Data correctness is fine; this only affects how the header reads. Easy to mistake for a "no data" bug when the date portion happens to match, hence worth fixing — but no rush.
Context
Surfaced while validating PR #35's --from feature end-to-end on a VPS after the _subscription/Notes work merged via #36. The actual filtering works correctly; only the label is misleading.
Summary
When running
hermes-telemetry stats <subcmd> --from <iso>without a matching--to, the date-range label in the header is rendered as"X to X"and loses any time-of-day information from--from, even though the underlying query is doing the right thing.This is purely a cosmetic / UX bug. The data returned is correct.
Repro
On a VPS that received API calls earlier in the day (before noon UTC) and none since:
Both labels read "2026-06-16 to 2026-06-16", so the second call looks like an empty/inverted range even though the data is just genuinely empty (no API calls between 12:00 UTC and now).
Root cause
Two contributing pieces in PR #35:
telemetry_cli._resolve_date_range(telemetry_cli.py:169-178) auto-fillsdate_to = datetime.now(timezone.utc).isoformat()whenever the user passes only--from. The DB layer doesn't need this — with thedatetime('now')upper-bound fix already in this branch,date_to=Noneworks correctly as "no upper bound" — so the auto-fill is purely cosmetic plumbing into the label.stats._date_range_label(stats.py:58-65) slices both ISO timestamps to[:10], stripping the time-of-day. Combined with (1), both ends collapse to today's date when--fromis timestamped, producing"2026-06-16 to 2026-06-16".Expected behaviour
--from 2026-06-16T12:00:00Z(no--to) → label"since 2026-06-16T12:00:00".--from 2026-06-16(no--to) → label"since 2026-06-16".--from 2026-06-10 --to 2026-06-15→ label"2026-06-10 to 2026-06-15"(unchanged)./statsslash command (in-chat) should behave the same way once the change lands.Proposed fix
Two small changes:
telemetry_cli._resolve_date_range, return(args.date_from, args.date_to)verbatim — don't synthesizedate_to.stats._date_range_label, strip the+00:00/Zsuffix and drop the time portion only when it is exactlyT00:00:00(otherwise keepT12:00:00, etc., so the time slice is visible). Trim microseconds when present.Add regression tests:
--from <ts>(no--to) renders"since <ts>", not"X to X".--fromkeeps the time in the label.Severity
Minor. Data correctness is fine; this only affects how the header reads. Easy to mistake for a "no data" bug when the date portion happens to match, hence worth fixing — but no rush.
Context
Surfaced while validating PR #35's
--fromfeature end-to-end on a VPS after the_subscription/Noteswork merged via #36. The actual filtering works correctly; only the label is misleading.