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

Ouverte
  • Quelque chose ne va pas ?
#1,669 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 6 jours

@NUAAwqy y travaille déjà.

Depuis le 12/11/2026.

  • #1670 par @NUAAwqy — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
78/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
go
Domaine
api, backend

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Go
Étoiles
15.7k
Forks
1.4k
Merge moyen
9 j 6 h
PR mergées (30 j)
8

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Propose un modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/answer

Toutes les issues de apache/answer

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.