固定的 Everett 時區偏移，在夏令時間會出錯

一個分布式團隊地圖將其美國樞紐標示為馬薩諸塞州埃弗里特，並將標籤儲存為 UTC-5該標籤對於東部標準時間是正確的，但在日光節約時間期間比埃弗雷特晚一小時。

重現

公開職業頁面的來源已儲存 data-hub-tz="UTC-5"; 同時使用其可訪問名稱 USA (HQ) Hub (UTC-5)。我使用 IANA 區域標識符檢查了兩個日期：

from datetime import datetime
from zoneinfo import ZoneInfo

zone = ZoneInfo("America/New_York")
for day in (datetime(2026, 1, 15, 12), datetime(2026, 9, 15, 12)):
    local = day.replace(tzinfo=zone)
    print(local.isoformat(), local.utcoffset())

觀察到的輸出：

2026-01-15T12:00:00-05:00 -1 day, 19:00:00
2026-09-15T12:00:00-04:00 -1 day, 20:00:00

瀏覽器原生路徑給出相同的九月結果：

const part = new Intl.DateTimeFormat("en-US", {
  timeZone: "America/New_York",
  timeZoneName: "shortOffset",
}).formatToParts(new Date("2026-09-15T12:00:00Z"))
  .find(({ type }) => type === "timeZoneName");

console.assert(part.value === "GMT-4", part.value);

這使用 Intl.DateTimeFormat，其行為由 ECMA-402.

建議修復

如果地圖表示該位置的民用時區，請在數據中使用穩定的標識符和非季節性的可見標籤：

data-hub-time-zone="America/New_York"
data-hub-tz-label="ET (UTC−5 standard / UTC−4 daylight)"

如果介面需要當前偏移量，則在渲染時推導它 America/New_York; 不要編碼 UTC-5 作為真實來源。

接受檢查

1. 可訪問標籤和視覺提示使用相同的文本。
2. 一月的固定項產生 GMT-5 而九月的裝置結果是 GMT-4.
3. 儲存的區域依然存在 America/New_York，因此未來的日光節約時間變更不需要內容編輯。

範圍邊界

這項發現無法推斷網站實際採用的排班規則。如果 UTC-5 故意意味著全年運行偏移，適當的修復是明確說明該意圖，而不是應用動態時區變更。

由 Tiee 準備。公開頁證據、Python 輸出、JavaScript 斷言及最終措辭在 AI 助理起草後皆經人工審核。