Homepage news list shows every article one day early for viewers west of UTC

[sanity]

Noticed while adding the "Services Without Servers" talk in #79. Not caused by that PR, this is pre-existing and affects every item in the list.

Problem

On the homepage, the News list renders each article's date one day early for anyone in a timezone behind UTC. Checked against the live site just now with the browser timezone set to America/Chicago:

Live homepage shows	Article front matter
March 27, 2026	2026-03-28
February 5, 2026	2026-02-06
December 24, 2025	2025-12-25
April 9, 2025	2025-04-10

Every one is off by a day. /about/news/ and /about/video-talks/ are correct, so it is only the homepage.

Cause

latest-news.html takes two paths. The plain path formats server-side and is fine:

{{ .Date.Format "January 2, 2006" }}

The include-releases="true" path (which the homepage uses, so it can merge in the latest GitHub release) hands dates to the browser instead:

(dict "date" (.Date.Format "2006-01-02T15:04:05Z") ...)

return date.toLocaleDateString("en-US", { year: "numeric", month: "long", day: "numeric" });

Article front matter carries a date with no time, so Hugo emits midnight UTC. toLocaleDateString then converts that instant into the viewer's zone, and midnight UTC is the previous evening anywhere west of UTC:

$ TZ=America/Chicago node -e "console.log(new Date('2026-07-24T00:00:00Z').toLocaleDateString('en-US',{year:'numeric',month:'long',day:'numeric'}))"
July 23, 2026

GitHub release entries are unaffected because published_at carries a real time of day.

Suggested fix

Format the article dates server-side, where Hugo already knows the intended calendar date, and only fall back to the JS formatter for release entries that genuinely need timezone conversion. Roughly: add a dateDisplay field to the JSON built in latest-news.html using .Date.Format "January 2, 2006", then in renderNews use item.dateDisplay when present and formatDate(item.date) otherwise.

Sorting can keep using the raw timestamp, so ordering is unaffected.

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-07-29T16:13:17.228020706+00:00
Issue hash: d58b72bc

Value Assessment

The code exactly matches the issue's description — line 15 formats dates as 2006-01-02T15:04:05Z (midnight UTC, no time-of-day), and lines 27-30's formatDate runs new Date(dateStr).toLocaleDateString('en-US', ...) in the browser's local zone, which is the exact bug described. The plain (non-include-releases) branch at line 75 does format server-side and is unaffected, matching the issue's claim that /about/news/ and /about/video-talks/ are fine. This issue is fully current and unfixed.

Relevance: Confirmed still present, verified by direct code read — not stale.

User impact: This affects the homepage specifically (the site's highest-traffic page), for every visitor in any timezone west of UTC (all of the Americas, and effectively most of the site's likely English-speaking audience). It's a permanent, 100%-reproducible off-by-one-day display bug on every single news item, not an edge case. It's cosmetic (no broken functionality, no data loss) but is the kind of visible correctness bug that undermines trust in a page that also functions as the project's public-facing "we ship" credibility signal.

Strategic alignment: Low-to-moderate. It doesn't advance a roadmap item, but homepage polish/correctness matters for a project trying to look actively maintained to newcomers evaluating Freenet.

Blocking factor: None — doesn't block other work or contributions.

Urgency: No hard deadline, but it's trivial to fix (the issue even proposes the exact fix: add a dateDisplay field formatted server-side via .Date.Format "January 2, 2006" and prefer it in renderNews) and has been live and wrong for an unknown period, so there's no reason to defer it. Given the small effort-to-benefit ratio, this is a good quick win to knock out, even though it's not urgent.

Cost Assessment

Confirms the issue exactly matches current code. This is a well-scoped, low-cost fix.

Relevance: Fully current — the file at hugo-site/themes/freenet/layouts/shortcodes/latest-news.html matches the issue's description line-for-line (lines 15, 27-30, 40). No rethinking needed; the suggested fix applies directly.

Scope: Single file, single shortcode template (latest-news.html, 81 lines total). Two small edits: add dateDisplay to the Go template's JSON dict (line 15) using .Date.Format "January 2, 2006", and update renderNews's render loop (line 40) to prefer item.dateDisplay when present, falling back to formatDate(item.date) for GitHub release entries which lack that field. No other templates, partials, or JS files are involved — this shortcode is self-contained (inline <script> block).

Complexity: Trivial. No tricky edge cases — sorting (line 34, new Date(b.date) - new Date(a.date)) stays keyed on the raw ISO timestamp so ordering is unaffected by the display-string change; release items simply lack dateDisplay and correctly fall through to the JS formatter, which is appropriate since published_at carries a real time and genuinely needs timezone conversion.

External dependencies: None. Pure static-site template change, no API/service coordination, no build pipeline changes.

Risk: Very low. The change is additive-and-substitutive within one shortcode; the only consumer is this template's own rendering path, and the non-include-releases branch (already correct) is untouched.

Testing effort: No automated test harness exists for Hugo template output in this repo (Hugo builds are typically visually verified). Verification is manual: run cargo make dev / hugo server -D, load the homepage with browser devtools timezone overridden to something west of UTC (e.g. America/Chicago), and confirm article dates match front matter while the release entry still displays correctly. This is a 5-minute manual check, consistent with the repo's existing practice of visual verification for Hugo/UI changes.

Overall: this is a very low-cost fix — roughly a 10-minute change plus a quick manual timezone-override check in the browser.

---

Generated by issue-prioritizer