에버렛의 시차를 고정하면 서머타임에 한 시간 어긋납니다

분산 팀 맵은 미국 허브를 매사추세츠주 에버렛으로 식별하고 라벨을 다음과 같이 저장합니다 UTC-5. 그 라벨은 동부 표준시(Eastern Standard Time)에 맞지만, 일광 절약 시간 동안 에버렛(Everett)보다 한 시간 늦습니다.

재현

공개 채용 페이지 소스가 저장되었습니다. 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

브라우저-네이티브 경로는 동일한 9월 결과를 제공합니다:

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. 1월 고정 요소 생성 GMT-5 그리고 9월 일정이 산출됩니다 GMT-4.
3. 저장된 영역은 그대로 남아 있습니다. America/New_York, 따라서 향후 일광 시간 변경 시 콘텐츠 편집이 필요하지 않습니다.

범위 경계

이 발견만으로 사이트가 의도한 일정 운영 방침을 단정할 수는 없습니다. UTC-5 고의적으로 연중 운영 오프셋을 의미하며, 동적 시간대 변경을 적용하기보다는 그 의도를 명시적으로 진술하는 것이 적절한 수리입니다.

Tiee가 준비함. 공개 페이지 증거, Python 출력, JavaScript 주장 및 최종 문안은 AI 지원 초안 작성 후 수동 검토됨.