Server-rendered <time datetime> and JSON-LD dates ignore the site time zone (server-local wall clock labeled as UTC)

Offen
  • Stimmt etwas nicht?
#1,669 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 6 Tagen

@NUAAwqy arbeitet bereits daran.

Seit 12.11.2026.

  • #1670 von @NUAAwqy — offen

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
78/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
go
Bereich
api, backend

Rechercherichtung

Start with internal/base/server/http_funcmap.go, especially timeFormatISO and translatorTimeFormat, then inspect JSON-LD date construction in internal/controller/template_controller.go and the time-zone behavior in pkg/day. Reproduce the examples using Asia/Tokyo and America/New_York; done means HTML dates, JSON-LD dates, and year-boundary decisions respect the configured zone, with the stated fallback for unknown zones.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Description

The server-rendered <time datetime="..."> attributes and the question-page JSON-LD dates ignore the site-configured time zone and mislabel the instant:

  1. The timeFormatISO template func (internal/base/server/http_funcmap.go) calls time.LoadLocation(tz) but discards the loaded location — the exact pattern fixed for day.Format in #1659 — and then formats the timestamp in the server's local zone with the layout "2006-01-02T15:04:05.000Z", where the trailing Z is a literal, not an ISO zone token. Every rendered <time datetime=...> (question detail ×4, comment, question list, tag detail) therefore carries the server-local wall clock labeled as UTC.

  2. The JSON-LD DateCreated fields in template_controller.go (jsonLD.MainEntity.DateCreated, accepted/suggested answer items) are built with time.Unix(...) in the server-local zone and serialized with that offset, so the structured SEO data carries the deployment's zone instead of the site's configured one (siteInfo.Interface.TimeZone, which the templates already receive and forward correctly).

  3. The year-boundary decision inside translatorTimeFormat (time.Unix(timestamp, 0).Format("2006") == time.Unix(now, 0).Format("2006")) compares calendar years in the server zone, not the display zone, so a post rendered shortly after New Year in the site zone can drop the year (or keep it) incorrectly whenever the two zones disagree.

Steps to reproduce

Executed against current master (standalone test invoking the real funcMap, process started with TZ=Asia/Shanghai):

timeFormatISO("Asia/Tokyo", 1700000000)      = 2023-11-15T06:13:20.000Z
  correct would be                            = 2023-11-15T07:13:20.000+09:00
timeFormatISO("America/New_York", 1700000000) = 2023-11-15T06:13:20.000Z
  correct would be                            = 2023-11-14T17:13:20.000-05:00

1700000000 is 2023-11-14T22:13:20Z. Both requested zones are ignored, and the UTC+8 wall clock is labeled Z. The same values feed every <time datetime="..."> in the rendered HTML and are indexed from there.

Expected behavior
  • timeFormatISO(tz, ts) renders the instant in tz (falling back to the server zone for empty/unknown zones, the same semantics #1659 established for day.Format) with a real ISO-8601 zone marker (+09:00, or Z only when the zone is UTC).
  • The JSON-LD dates use the site's configured zone.
  • The relative/absolute rendering decisions (same-year check) are made in the display zone.
Specifications
  • Version: current master (verified on a tarball of master, 2026-11-13)
  • Platform: linux/amd64, Go 1.24 module
  • Subsystem: internal/base/server/http_funcmap.go, internal/controller/template_controller.go, pkg/day
Possible Solution

Follow the semantics #1659 established: keep one zone-aware helper in pkg/day (e.g. FormatISO) used by timeFormatISO, drop the dead LoadLocation calls, make the same-year decision in the display zone, and render the JSON-LD time.Time values with .In(siteLoc). Happy to send a PR with regression tests covering the zones above plus the unknown-zone fallback.

Vorherrschende Sprache
Go
Sterne
15.7k
Forks
1.4k
Ø Merge
9 T. 6 Std.
Gemergte PRs (30 T.)
8

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/answer

Alle Issues in apache/answer

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.