시간대는 실제로 어떻게 작동하는가

시간대가 무엇이냐고 물으면 대부분은 지도 위의 세로 띠를 이야기합니다. 세계를 스물네 개의 같은 조각으로 나누고, 한 시간씩 떨어뜨리고, 경도가 그것을 다스린다는 그림입니다. 이 모형은 깔끔하고 기억하기 쉬우며, 언젠가 회의 하나를 날려 먹을 방식으로 틀렸습니다.

시간대는 어떤 정부가 관리하는, 특정 영역의 시계가 무엇을 가리킬지에 관한 이름 붙은 규칙의 묶음입니다. 규칙은 바뀔 수 있습니다. 정치적인 이유로, 경제적인 이유로, 때로는 2주 전 예고로 바뀝니다. 경도는 이 발상이 시작된 자리이지, 도착한 자리가 아닙니다.

이 발상은 어디에서 왔는가

1880년대 이전에는 마을마다 자기 시간을 지켰습니다. 기준은 지역의 정오, 곧 해가 머리 위 자오선을 지나는 순간이었습니다. 브리스틀은 런던보다 10분 늦었지만 아무도 개의치 않았습니다. 10분이 문제가 될 만큼 빠르게 움직이는 것이 아직 없었기 때문입니다.

철도가 그것을 바꿨습니다. 열차가 10시 15분에 떠난다고 적힌 시간표는, 10시 15분이 노선 양 끝에서 다른 것을 뜻한다면 아무 쓸모가 없습니다. 1840년대에 이르러 영국 철도 회사들은 자기 노선망 전체에 런던 시간을 그냥 밀어붙였습니다. 미국은 1883년에 뒤를 따랐고, 철도 회사들이 스스로의 결정으로 나라를 네 개의 시간대로 잘랐습니다. 1884년 국제 자오선 회의는 그리니치를 본초 자오선으로 정해 세계에 공통의 잣대를 주었습니다.

이 역사에서 중요한 대목은, 시간대가 조율이라는 문제를 풀기 위해 그 문제를 안고 있던 조직들의 손으로 만들어졌다는 점입니다. 그것은 해가 어디 있는지에 대한 서술이었던 적이 한 번도 없습니다.

시간대가 실제로 담고 있는 것

권위 있는 기록은 IANA 시간대 데이터베이스이며, tzdata 또는 올슨 데이터베이스라고도 부릅니다. 텍스트 파일이고, 한 해에도 여러 번 갱신되며, 여러분이 쓰는 모든 운영체제와 브라우저와 프로그래밍 언어가 그 어떤 판본을 읽고 있습니다.

각 시간대에 대해 이렇게 기록합니다.

• America/New_York이나 Asia/Kathmandu 같은 식별자
• 그 시간대 역사의 각 시기에 적용되던 UTC 시차
• 그 시차가 바뀐다면 언제 바뀌는지에 대한 규칙
• 각 시기의 약어, 있는 경우에 한해

식별자는 지역/장소 관례를 따르고, 장소는 나라가 아니라 대표 도시입니다. 나라는 갈라지고 합쳐지며 국경과 무관하게 규칙을 바꾸기 때문입니다. America/Argentina/Buenos_Aires가 있는 이유는 아르헨티나의 주들이 한때 서로 다른 시간을 지켰기 때문입니다.

시간대가 무엇이 아닌지에 주목하세요. 그것은 시차가 아닙니다. America/New_York은 “UTC-5”가 아닙니다. 시차가 한 해의 일부는 UTC-5, 나머지는 UTC-4인 시간대이며, 제2차 세계대전 동안에는 일 년 내내 UTC-5에 머물렀고, 1966년 이전에는 다른 규칙으로 움직이던 시간대입니다. “UTC-5”를 저장해 놓고 그것을 뉴욕이라 부르는 것이야말로 소프트웨어에서 가장 흔한 시간대 결함입니다.

규칙은 바뀐다, 그것도 서서히가 아니라

2016년 튀르키예는 약 3주 전 예고로 서머타임을 버리고 UTC+3에 영구히 머물렀습니다. 2018년 북한은 남쪽과 다시 맞추려고 시계를 30분 옮겼습니다. 2022년 이란은 서머타임을 폐지했고, 같은 해 멕시코는 국토 대부분에서 이를 없앴습니다. 이집트는 2014년에 폐지했던 것을 2023년에 되살렸습니다.

그 하나하나가 tzdata 배포였고, 하나하나가 시차 표를 코드에 박아 둔 모든 시스템을 망가뜨렸습니다. 이 사이트의 모든 페이지 뒤에 있는 엔진이 여기 저장된 무엇이 아니라 실행 환경의 tzdata 사본에서 시차를 읽는 이유가 그것입니다. 다시 빌드하면 새 규칙이 들어오고, 손댈 것은 없습니다.

왜 시차가 모두 정시 단위가 아닌가

세계 인구의 약 5분의 1이 UTC로부터 정수 시간이 아닌 시차 위에서 살아갑니다. 인도는 UTC+05:30으로, 둘로 나눠도 될 만큼 넓은 나라에 대한 하나의 절충으로 정해진 값입니다. 네팔은 UTC+05:45이며, 그 45분에는 인도 시간으로부터의 독립을 드러내는 뜻도 있습니다. 채텀 제도는 UTC+12:45, 뉴펀들랜드는 UTC-03:30입니다.

시차가 정시 단위라고 전제하는 소프트웨어는 그저 반올림하는 데 그치지 않습니다. 수억 명에게 30분이나 45분 어긋난 답을 내놓습니다. 그것이야말로 통화 전이 아니라 통화 중에 드러나는 크기의 오류입니다.

현지 시각이 함수가 아닌, 한 해의 이틀

서머타임은 해마다 두 개의 불연속을 만들고, “이 현지 시각을 변환하라”가 보기보다 어려운 이유가 바로 그것입니다.

앞당김은 한 시간을 지웁니다. 뉴욕에서는 전환 당일 01:59:59 바로 다음이 03:00:00입니다. 현지 시각 02:30은 오지 않습니다. 누군가 그것을 입력하면 돌려줄 올바른 순간이 존재하지 않고, 대신 무엇을 돌려줄지에 대한 방침만 있습니다.

되돌림은 한 시간을 반복합니다. 01:30은 두 번 옵니다. 한 번은 서머타임에, 한 시간 뒤 다시 한 번 표준시에. 현지 시각만으로는 정말로 모호하며, 둘 중 어느 쪽을 뜻했는지 알아야 하지만 그것을 묻는 화면은 거의 없습니다.

이 사이트의 모든 도구는 두 경우 모두를 분명히 처리하고 무엇을 했는지 알려 줍니다. 조용히 하나를 고르는 것이야말로 일정이 한 시간 어긋난 채로, 통화가 시작되기 전까지 아무도 알아채지 못하는 경로입니다.

실무에서 이것이 뜻하는 바

작동 방식에서 세 가지 규칙이 따라 나오고, 잘못되는 일의 대부분이 여기에 들어갑니다.

1. 순간을 저장하고 현지 시각을 저장하지 마세요. UTC 타임스탬프는 모호하지 않습니다. 현지 시각은 타임스탬프에 시간대를 더하고, 그 까다로운 이틀에 대한 방침을 다시 더한 것입니다.
2. 시간대 식별자를 저장하고 시차를 저장하지 마세요. Europe/London은 규칙 변경에서도 살아남지만 UTC+0은 그러지 못하고, 어차피 반년은 틀립니다.
3. 보여 줄 때 실행 환경의 tzdata로 변환하세요. 저장할 때가 아니라, 그리고 직접 관리하는 표에서는 결코 아니게.

이 사이트가 시차에 대해 “마지막 빌드 기준”이라고 계속 붙이고, 현재 시각은 대신 여러분의 브라우저에서 계산하는 이유도 같습니다. 그 규칙은 우리가 얼려 둘 수 있는 것이 아닙니다.