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

Abierto
  • ¿Algo no está bien?
#1,669 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 6 días

@NUAAwqy ya está trabajando en esto.

Desde el 12/11/2026.

  • #1670 de @NUAAwqy — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
78/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
api, backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
15.7k
Forks
1.4k
Merge medio
9 d 6 h
PR fusionados (30 d)
8

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/answer

Todos los issues de apache/answer

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.