UTC·오프셋·IANA 타임존: 시차 계산이 틀리는 진짜 이유

시차 계산이 틀리는 사고의 대부분은 산수를 잘못해서가 아니라, 서로 다른 두 개념을 같은 것으로 취급해서 생깁니다. 바로 오프셋과 타임존입니다. 이 둘을 구분하는 순간 대부분의 사고가 사라집니다.

UTC — 기준점

UTC(협정 세계시)는 전 세계 시간의 기준입니다. 어떤 도시의 시간도 아니고, 서머타임도 없으며, 연중 변하지 않습니다. 모든 지역의 시각은 'UTC로부터 얼마나 떨어져 있는가'로 표현됩니다. 영국의 GMT와 실무상 같은 값으로 쓰이지만 둘은 다른 개념이고, 무엇보다 런던은 여름에 GMT가 아닙니다. 기준을 말할 때는 UTC를 쓰는 편이 안전합니다.

오프셋 — '지금 이 순간'의 차이

UTC+9, UTC−5 같은 표기가 오프셋입니다. 오프셋은 특정 시점의 상태값이지, 그 지역의 정체성이 아닙니다. 뉴욕은 겨울에 UTC−5, 여름에 UTC−4입니다. 즉 뉴욕의 오프셋은 하나가 아닙니다. '뉴욕의 오프셋이 뭐예요?'라는 질문에는 날짜 없이는 답할 수 없습니다.

IANA 타임존 — 규칙의 이름

Asia/Seoul, America/New_York, Europe/London 같은 문자열이 IANA 타임존 식별자입니다. 이건 오프셋이 아니라 규칙의 이름입니다. '이 지역은 언제부터 언제까지 서머타임을 적용하고, 그때 오프셋이 얼마가 된다'는 규칙 전체를 가리킵니다. 그래서 타임존 ID 하나에는 과거와 미래의 오프셋 변경 이력이 전부 들어 있습니다.

식별자는 대체로 '대륙/대표도시' 형태이고, 공백은 밑줄로 씁니다(America/New_York, America/Sao_Paulo). 나라 이름이 아니라 도시 이름을 쓰는 것은 국경이 바뀌어도 식별자가 살아남게 하려는 설계입니다. 그래서 '한 나라 = 한 타임존'이라는 가정은 처음부터 성립하지 않습니다.

따라서 올바른 계산 방식은 이렇습니다. 타임존 ID와 날짜를 함께 넣으면, 그때의 오프셋이 결정됩니다. 오프셋을 먼저 정하고 시작하면 서머타임 전환을 넘길 수 없습니다.

타임존 데이터는 정치적으로 바뀐다

타임존 규칙은 물리 상수가 아니라 각국 정부의 결정입니다. 그래서 IANA 타임존 데이터베이스는 해마다 여러 차례 갱신됩니다. 러시아는 2014년에, 브라질은 2019년에, 이란은 2022년에 서머타임을 폐지했습니다. 이런 변경은 예고 기간이 짧을 때가 많고, 그때마다 오프셋을 박아둔 시스템이 조용히 틀리기 시작합니다.

식별자 자체도 바뀝니다. Asia/Calcutta는 Asia/Kolkata로, Europe/Kiev는 Europe/Kyiv로 이름이 바뀌었습니다. 옛 이름은 별칭으로 남아 계속 동작하므로 급히 고칠 필요는 없지만, 새로 저장하는 값은 현재 이름을 쓰는 편이 좋습니다.

1시간 단위가 아닌 오프셋

모든 시차가 1시간 단위라고 가정하는 것도 흔한 실수입니다. 인도는 UTC+5:30, 네팔은 UTC+5:45, 이란은 UTC+3:30, 호주 중부 지역은 UTC+9:30, 뉴질랜드 채텀 제도는 UTC+12:45를 씁니다. 뭄바이와 회의를 잡을 때 '오전 10시'가 아니라 '오전 10시 30분'이 되는 이유입니다. 회의 시각은 반드시 분 단위까지 명시하세요.

범위도 생각보다 넓습니다. 오프셋은 UTC−12부터 UTC+14까지 존재하고, 키리바시의 라인 제도가 UTC+14입니다. 양 끝을 합치면 같은 순간에 지구상의 날짜가 이틀에 걸쳐 있습니다. '오늘'이라는 단어가 참석자마다 다른 날을 가리킬 수 있다는 뜻입니다.

약어는 식별자가 아니다

KST·EST·CET 같은 세 글자 약어는 사람끼리 쓰기엔 편하지만 식별자로 쓰기엔 위험합니다. 표준으로 관리되는 이름이 아니라 관행이기 때문에, 같은 약어가 여러 지역을 가리키는 경우가 흔합니다. CST는 미국 중부시간이면서 중국 표준시이기도 하고, IST는 인도·아일랜드·이스라엘에서 각각 다른 값입니다.

게다가 약어는 계절에 따라 바뀝니다. 뉴욕은 겨울에 EST, 여름에 EDT입니다. 런던은 GMT와 BST를 오갑니다. 그래서 'EST 기준 오후 3시'라고 적힌 문서를 여름에 읽으면 그 시각이 실제로 언제였는지 확정할 수 없습니다. 작성자가 정확히 EST를 의도했는지, 그냥 '뉴욕 시간'을 뜻했는지 알 수 없기 때문입니다.

사람에게 보여줄 때는 약어를 써도 됩니다. 다만 저장하고 계산하는 값은 항상 타임존 ID여야 합니다. 문서에 적을 때도 'EST'보다 '뉴욕 시간'이 덜 위험합니다. 후자는 계절에 따라 알아서 해석되지만 전자는 특정 오프셋을 못 박기 때문입니다.

존재하지 않는 시각, 두 번 존재하는 시각

서머타임 전환일에는 하루가 24시간이 아닙니다. 봄에 시계를 한 시간 앞당기는 날에는 특정 한 시간이 통째로 건너뛰어집니다. 그날 그 지역에는 오전 2시 30분이 존재하지 않습니다. 가을에 되돌리는 날에는 반대로 같은 시각이 두 번 옵니다 — 오전 1시 30분이 두 번 지나가고, 그 둘은 서로 다른 순간입니다.

이게 실무에서 문제가 되는 지점은 분명합니다. 존재하지 않는 시각에 회의를 잡으면 캘린더마다 다르게 해석합니다. 어떤 앱은 한 시간 뒤로 밀고, 어떤 앱은 앞으로 당깁니다. 두 번 오는 시각에 알림을 걸면 두 번 울리거나 엉뚱한 쪽에서 울립니다. 전환일 새벽에 걸치는 일정은 아예 만들지 않는 것이 가장 확실한 회피책입니다.

미래의 약속은 UTC로만 저장하면 안 된다

'시각은 UTC로 저장한다'는 원칙에는 중요한 예외가 있습니다. 이미 지나간 일(로그, 결제 시각, 접속 기록)은 UTC로 저장하는 것이 맞습니다. 그 순간은 다시 바뀌지 않기 때문입니다. 그런데 미래의 약속은 다릅니다.

'2029년 3월 15일 서울 오전 9시'라는 약속을 지금 UTC로 환산해 저장했다고 해봅시다. 그 사이에 한국이 서머타임을 도입하거나 어떤 나라가 표준시를 바꾸면, 저장해 둔 UTC 값은 더 이상 '현지 오전 9시'가 아닙니다. 약속은 '현지 오전 9시'였는데 시스템은 절대 시각을 기억하고 있어서, 규칙이 바뀌는 순간 조용히 어긋납니다.

실무에서 지킬 3가지

1. 사람·일정·회의는 오프셋이 아니라 타임존 ID로 저장한다. 'UTC+9'가 아니라 'Asia/Seoul'로.
2. 저장하는 시각 자체는 UTC로 통일한다. 표시할 때만 사용자의 타임존으로 변환한다.
3. 시차를 물어볼 때는 항상 날짜를 함께 묻는다. 날짜 없는 시차 질문에는 정답이 없습니다.

세 번째가 특히 중요합니다. '서울이랑 런던 몇 시간 차이죠?'라는 질문은 겨울이면 9시간, 여름이면 8시간이라는 서로 다른 답을 갖습니다. 둘 다 맞고 둘 다 틀립니다. 날짜를 붙이는 순간 답은 하나가 됩니다.

정리

지금까지의 내용을 한 문장으로 줄이면 이렇습니다. 오프셋은 결과이고 타임존은 규칙입니다. 결과를 저장하면 규칙이 바뀔 때 조용히 틀리고, 규칙을 저장하면 결과는 언제든 다시 계산할 수 있습니다. 시차 계산에서 나오는 사고의 대부분은 이 한 문장으로 설명됩니다.

그래서 실무에서 필요한 것은 시차 표가 아니라 습관입니다. 날짜 없이 시차를 묻지 않기, 약어 대신 도시로 적기, 미래의 약속은 현지 시각과 타임존 ID를 함께 남기기. 이 세 가지면 대부분의 상황에서 계산이 틀릴 자리가 없어집니다. 반대로 이 중 하나라도 빠지면, 평소에는 멀쩡하다가 서머타임 전환일이나 규칙 변경일에만 틀리는 가장 찾기 어려운 형태의 오류가 남습니다.