fix: News briefing date a day behind (UTC render)

[protostatis]

Problem

On prod, the News page headline date (Tuesday, August 19 · Briefing) shows one day behind the actual briefing date, every day.

Root cause

The trending payload's date field is a calendar date only (e.g. "2026-07-24"), not an instant. formatCalendarDate in dashboard-frontend/src/pages/News.jsx did new Date("2026-07-24") — JS parses that as UTC midnight — then toLocaleDateString shifted it into the viewer's local timezone. For any viewer west of UTC (e.g. US Central) that rolls the calendar day back by one. Reproduced locally: a CT viewer saw July 23 instead of July 24.

The backend value (data/trending_today.json → date: "2026-07-24") is correct; the bug is purely client-side display.

Fix

Detect date-only strings, anchor them to UTC midnight, and format with timeZone: "UTC" so the displayed calendar day always matches the stored date regardless of viewer timezone. Verified: now renders July 24 for a CT viewer.

Notes

• dist/ is not tracked; prod builds the frontend from source, so this fix takes effect on next deploy after merge.
• Other frontend date usages were reviewed: chart axis labels build from local components and round-trip consistently; SourceTable/BeliefsSummary/FreshnessChip format true timestamps (instants), which is correct. Only the News hero date was affected.

🤖 Generated with Claude Code

[protostatis]

Sky's Code Review

This frontend-only bugfix corrects the News page headline date rendering. The root cause was that formatCalendarDate passed a date-only string like "2026-07-24" directly to new Date(), which JavaScript parses as UTC midnight, then toLocaleDateString shifted it into the viewer's local timezone, rolling the calendar day back by one for viewers west of UTC. The fix detects date-only strings with a regex, anchors them to UTC midnight by appending T00:00:00Z, and forces timeZone: 'UTC' in toLocaleDateString so the rendered calendar day always matches the stored date. The change is minimal, correct, and well-scoped to a single helper function.

Verdict: Approve

Comments

• The fix is correct and idiomatic. The Number.isNaN(date.getTime()) guard is retained, so invalid or non-date strings still return null rather than throwing.
• Consider whether a small unit test for formatCalendarDate with a date-only string (asserting 'UTC' timezone renders the stored day regardless of the runner's local TZ) would prevent future regressions — this is a suggestion, not a blocker.

---

Reviewed by Sky — Unchained Sky engineering agent

Inline Comments (could not attach to lines)

dashboard-frontend/src/pages/News.jsx:26 — The date-only regex /^\d{4}-\d{2}-\d{2}$/ is correct for the backend's date values (e.g. "2026-07-24"). No change needed; just noting that if other callers ever pass non-ISO dates to formatCalendarDate, they'd fall through to plain new Date() and the existing NaN guard on the next line already handles invalid input safely.

dashboard-frontend/src/pages/News.jsx:27 — Appending T00:00:00Z and forcing timeZone: 'UTC' (line 34) both anchor the value to UTC, so the two are redundant but complementary — the explicit timeZone is the key fix and the Z suffix removes any ambiguity. No action required.