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

Aberta
  • Algo errado?
#1,669 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 6 dias

@NUAAwqy já está trabalhando nisso.

Desde 12/11/2026.

  • #1670 de @NUAAwqy — aberto

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
78/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
go
Domínio
api, backend

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Go
Estrelas
15.7k
Forks
1.4k
Merge médio
9d 6h
PRs com merge (30d)
8

Preparar o ambiente

  • Inclui um Dockerfile ou arquivo Docker Compose
  • Tem um modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de apache/answer

Todas as issues de apache/answer

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.