UTC·오프셋·IANA 타임존: 시차 계산이 틀리는 진짜 이유
시차 계산이 틀리는 사고의 대부분은 산수를 잘못해서가 아니라, 서로 다른 두 개념을 같은 것으로 취급해서 생깁니다. 바로 오프셋과 타임존입니다.
UTC — 기준점
UTC(협정 세계시)는 전 세계 시간의 기준입니다. 어떤 도시의 시간도 아니고, 서머타임도 없으며, 연중 변하지 않습니다. 모든 지역의 시각은 'UTC로부터 얼마나 떨어져 있는가'로 표현됩니다.
오프셋 — '지금 이 순간'의 차이
UTC+9, UTC−5 같은 표기가 오프셋입니다. 오프셋은 특정 시점의 상태값이지, 그 지역의 정체성이 아닙니다. 뉴욕은 겨울에 UTC−5, 여름에 UTC−4입니다. 즉 뉴욕의 오프셋은 하나가 아닙니다.
가장 흔한 버그
'뉴욕 = UTC−5'라고 코드나 문서에 박아두는 것. 이러면 서머타임 기간인 3월~11월 동안 계산이 1시간씩 틀립니다. 1년 중 8개월이 틀린 셈입니다.
IANA 타임존 — 규칙의 이름
Asia/Seoul, America/New_York, Europe/London 같은 문자열이 IANA 타임존 식별자입니다. 이건 오프셋이 아니라 규칙의 이름입니다. '이 지역은 언제부터 언제까지 서머타임을 적용하고, 그때 오프셋이 얼마가 된다'는 규칙 전체를 가리킵니다.
따라서 올바른 계산 방식은 이렇습니다. 타임존 ID와 날짜를 함께 넣으면, 그때의 오프셋이 결정됩니다. 오프셋을 먼저 정하고 시작하면 서머타임 전환을 넘길 수 없습니다.
이 도구가 계산하는 방식
타임존 스케줄러는 오프셋을 저장하지 않습니다. 도시마다 IANA 타임존 ID를 갖고 있고, 선택한 날짜를 함께 넣어 브라우저에 내장된 IANA 타임존 데이터베이스로 그때의 오프셋을 매번 새로 구합니다. 그래서 서머타임 전환이 자동으로 반영됩니다.
실무에서 지킬 3가지
- 사람·일정·회의는 오프셋이 아니라 타임존 ID로 저장한다. 'UTC+9'가 아니라 'Asia/Seoul'로.
- 저장하는 시각 자체는 UTC로 통일한다. 표시할 때만 사용자의 타임존으로 변환한다.
- 시차를 물어볼 때는 항상 날짜를 함께 묻는다. 날짜 없는 시차 질문에는 정답이 없습니다.
30분·45분 오프셋도 있다
모든 시차가 1시간 단위라고 가정하는 것도 흔한 실수입니다. 인도는 UTC+5:30, 네팔은 UTC+5:45, 호주 일부 지역은 UTC+9:30을 씁니다. 뭄바이와 회의를 잡을 때 '오전 10시'가 아니라 '오전 10시 30분'이 되는 이유입니다. 회의 시각은 반드시 분 단위까지 명시하세요.
읽은 내용을 바로 적용해 보세요. 참석자 도시를 올려두면 겹치는 업무시간이 한눈에 보입니다.
회의시간 조율기 열기