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

オープン
  • 何か問題がありますか？
#1,669 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 6 日以内に返信

@NUAAwqy がすでに取り組んでいます。

2026年11月12日 から。

  • #1670 @NUAAwqy による — オープン

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
78/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go
領域
api, backend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Go
スター
15.7k
フォーク
1.4k
平均マージ
9日 6時間
マージ済み PR（30日）
8

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/answer のほかの issue

apache/answer の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。