🕒 타임존 변환 · 세계 시계
지정한 일시를 여러 타임존 (IANA 400+)에 동시 변환. 기본 8개 도시 표시, DST 자동 고려, UTC 오프셋 표시, 실시간 갱신.
🔒 개인정보 보호
- ・모든 변환은 브라우저의 Intl.DateTimeFormat 으로 완결
- ・입력한 일시는 서버로 전송되지 않습니다
| 도시 / 타임존 | 날짜 | 시각 | UTC 오프셋 | DST |
|---|
📖 자주 걸리는 지점
IANA 타임존(400 개 이상)을 골라 세계 시계를 늘어놓고 지정한 일시를 각 도시의 현지 시각으로 변환합니다. DST 는 Intl.DateTimeFormat 이 자동으로 고려하며 처리는 브라우저 안에서 끝납니다. 표시되고 있는 시각은 정확하지만 그것을 예정으로 저장하는 단계에서 깨집니다 — 타임존은 지역의 속성이지 고정된 오프셋이 아닙니다. 이 차이가 아래 모든 것의 원인입니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 정례 회의가 연 2 회 한 시간 어긋난다 | DST 의 전환일은 나라마다 다릅니다. 미국은 3 월 둘째 일요일부터 11 월 첫째 일요일, EU 는 3 월 마지막 일요일부터 10 월 마지막 일요일입니다. 이 차이 때문에 3 월 중순에서 하순, 10 월 하순에서 11 월 상순에는 뉴욕과 런던의 시차가 평소의 5 시간이 아니라 4 시간이 됩니다 — 연 2 회, 몇 주만 나타나는 어긋남 기간 입니다. 일본은 DST 가 없으므로 일본 쪽 시각을 고정하면 상대 쪽이 움직이고 상대 쪽을 고정하면 일본 쪽이 움직입니다. 남반구는 더 반대로 오스트레일리아는 10 월에 시작해 4 월에 끝납니다. | 회의 안내에는 양쪽의 현지 시각을 쓰세요 — 도쿄 10:00 / 뉴욕 21:00(전날) 처럼 병기하면 어긋남 기간에도 상대가 알아챌 수 있습니다. 캘린더 초대를 쓰는 경우에는 반드시 타임존과 함께 보내세요 — 주요 캘린더는 IANA 이름으로 예정을 보관하므로 DST 의 전환을 자동으로 따라갑니다. 해서는 안 되는 것은 오프셋으로 고정하는 것입니다 — UTC+9 의 10 시 라고 기록하면 상대의 캘린더에서는 DST 때마다 움직입니다. 정례 회의는 전환일 직후에 한 번만 이번 주도 같은 시각이 맞습니까 라고 확인하는 습관을 들이면 사고가 거의 없어집니다. |
| 시차가 정수 시간이라고 믿고 있다 | 시차에는 30 분 단위와 45 분 단위의 지역이 있습니다. 인도는 +05:30, 네팔은 +05:45, 이란은 +03:30, 뉴펀들랜드는 -03:30, 그리고 뉴질랜드의 채텀 제도는 +12:45 입니다. 시차 = 정수 라는 전제로 코드를 쓰면 이들 지역에서만 조용히 30 분 어긋납니다 — 목록에 나오지 않는 지역이므로 테스트에서도 알아채지 못합니다. DST 의 폭도 1 시간이라고는 할 수 없어 오스트레일리아의 로드하우섬은 30 분만 앞당깁니다. |
오프셋은 분 단위로 보관하세요 — +9 가 아니라 +540 입니다. UI 에 표시할 때도 소수로 쓰지 마세요(+5.5 는 +05:30 이라고 써야 하고 +5.75 는 오해를 부릅니다). 애초에 오프셋을 직접 계산하지 않는 것이 가장 확실합니다 — Intl.DateTimeFormat 이나 각 언어의 표준 일시 라이브러리에 IANA 타임존 이름을 넘기면 30 분 단위도 DST 도 규칙의 변경도 전부 처리해 줍니다. 타임존 계산을 직접 만들고 싶어졌다면 그것은 잘못의 징조입니다 — 예외가 너무 많아 올바르게 쓸 수 있는 사람은 거의 없습니다. |
| 타임존의 약칭을 써서 통하지 않는다 | 세 글자 약칭은 유일하지 않습니다. CST 는 미국 중부 표준시(UTC-6) · 중국 표준시(UTC+8) · 쿠바 표준시(UTC-5) 세 가지를 가리킬 수 있습니다. IST 도 인도(UTC+5:30) · 아일랜드(UTC+1) · 이스라엘(UTC+2) 중 하나입니다. 게다가 약칭은 DST 로 바뀝니다 — 미국 동부는 겨울이 EST, 여름이 EDT 이므로 EST 의 9 시라고 쓰인 예정이 여름 날짜를 가리키고 있다면 그것은 모순입니다. 국제적인 주고받기에서 약칭을 쓰면 상대가 다른 시각으로 해석해도 어느 쪽도 틀리지 않습니다. |
저장과 통신에는 IANA 이름(Asia/Tokyo · America/New_York)을 쓰세요 — 이는 유일하며 DST 의 규칙도 역사적인 변경도 포함하고 있습니다. 약칭은 사람에게 보여 주는 표시에만 쓰고 그 경우에도 반드시 도시 이름을 곁들이세요(도쿄 시간(JST)). 문장으로 쓸 때는 일본 시간 10 월 5 일 10:00(UTC+9) 처럼 지역 · 날짜 · 시각 · 오프셋을 전부 쓰는 것이 가장 오해가 적습니다. 상대가 어느 타임존에 있는지 모르는 경우에는 UTC 로 쓰세요 — 누구에게나 등거리이고 변환의 필요는 생기지만 오해는 생기지 않습니다. |
타임존 데이터베이스(tzdata)는 연 몇 차례 갱신됩니다. 각국은 지금도 서머타임의 도입 · 폐지 · 기간의 변경을 계속하고 있으며 2022 년에 멕시코가 거의 전 국토에서 서머타임을 폐지했고 요르단과 시리아는 연중 서머타임으로 고정했으며 EU 는 폐지를 계속 논의하고 있습니다. 즉 타임존의 규칙은 코드가 아니라 데이터이며 그 데이터는 낡습니다 — 컨테이너 이미지나 OS 의 버전을 고정하면 어느 날을 경계로 그 지역의 시각만 한 시간 어긋나기 시작합니다. 베이스 이미지의 갱신은 보안뿐 아니라 이 이유로도 필요합니다. 운용의 원칙으로는 — 과거에 일어난 일은 순간이므로 UTC 로 저장하고 미래의 예정은 약속이므로 IANA 타임존 이름 + 로컬 시각으로 저장하세요. 로그의 타임스탬프를 IANA 이름으로 가질 의미는 없고 반대로 내년의 회의를 UTC 의 순간으로 저장하면 법 개정이 있은 시점에 현지의 10 시가 아니게 됩니다.
📖 사용법
-
1
모드 선택현재 시각 모드는 매초 갱신, 지정 모드는 입력 시각을 각 도시로 변환.
-
2
도시 추가/제거IANA 400+ 에서 도시를 추가하거나 X 로 제거합니다.
-
3
DST · UTC 오프셋 확인각 행에 UTC 오프셋과 DST 적용 여부가 표시됩니다.
❓ 자주 묻는 질문
IANA 타임존이란?
DST (서머타임) 는 자동 처리됩니까?
시각이 서버로 전송됩니까?
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.