타임존

타임존은 어느 지역의 시계가 지금 몇 시를 가리켜야 하는지 정해 줍니다. 같은 순간에도 서울의 시계와 런던의 시계는 다른 시각을 가리킵니다. 타임존을 알면 한 순간을 어느 지역의 시각으로든 바꿔 읽을 수 있습니다.

쉽고 빠른 이해

무슨 일을 하는 물건인가 — 어느 순간이 그 지역 시계로 몇 시인지 알려 줍니다. 세계 기준 시각으로 자정인 순간을 서울 타임존에 넣으면 오전 9시가 나옵니다.

왜 이렇게 하나 — 시각 숫자만으로는 어느 지역 시계로 읽은 값인지 모릅니다. 게다가 철마다 시계를 한 시간씩 옮기는 지역이 있습니다. 「몇 시간 차이」라는 숫자 하나로는 그 변화를 담지 못합니다.

어떻게 도나

지역마다 Europe/London 같은 이름을 붙입니다
그 이름 아래에 「언제부터 몇 시간 차이」라는 규칙을 모아 둡니다
순간과 이름을 주면 그날의 규칙을 찾아 지역 시각을 계산합니다

언제 쓰나 — 이미 지난 순간은 UTC 로 저장합니다. 타임존은 사용자에게 시각을 보여 줄 때와 앞날의 일정을 잡을 때 씁니다.

대가 — 규칙은 나라가 정합니다. 그리고 가끔 바뀝니다. 바뀐 규칙을 받아 두지 않으면 시각이 한 시간씩 틀립니다. 시계를 옮기는 날에는 없는 시각과 두 번 오는 시각도 생깁니다.

상세

이 절은 타임존이 무엇을 정하는지, 오프셋과 무엇이 다른지, 이름이 어떻게 생겼는지를 차례로 봅니다. 끝에서는 백엔드 코드가 타임존을 어디서 만나는지 봅니다. 서울·런던·뉴욕 세 도시의 시각을 가지고 봅니다.

비행기가 내리면 기내 방송이 현지 시각을 알려 줍니다. 승객은 손목시계 바늘을 그 시각으로 돌립니다. 어느 도시에 언제 내렸는지만 알면 몇 시로 돌릴지가 정해집니다. 도시마다 정해진 이 규칙이 타임존입니다.

순간과 지역 시각

세계가 함께 맞추는 기준 시각이 있습니다. UTC(Coordinated Universal Time, 협정 세계시)입니다. 서버가 여러 나라에 흩어져 있어도 이 기준 하나로 「같은 순간」을 가리킬 수 있습니다.

같은 순간이라도 사람이 보는 시계는 지역마다 다릅니다. 겨울 어느 날 UTC 로 0시인 순간에 서울 시계는 오전 9시를 가리킵니다. 런던 시계는 0시, 뉴욕 시계는 전날 저녁 7시입니다. 이렇게 그 지역 시계가 가리키는 값을 지역 시각이라고 부릅니다.

타임존은 순간을 지역 시각으로 바꾸는 규칙입니다. 한 타임존 안에서는 모든 시계가 같은 시각을 가리킵니다. 서울과 부산은 같은 타임존이라 시계가 늘 같습니다.

오프셋만으로는 모자라는 까닭

지역 시각이 UTC 와 얼마나 벌어져 있는지를 UTC 오프셋이라고 합니다. 서울은 UTC 보다 9시간 앞서서 +09:00 입니다. 기준에서 떨어진 거리를 뜻하는 오프셋이라는 말을 시간에 쓴 것입니다.

서울은 일 년 내내 +09:00 입니다. 그러면 타임존이 곧 오프셋인 것처럼 보입니다. 런던은 그렇지 않습니다.

런던은 겨울에 UTC 와 같은 +00:00 입니다. 봄이 되면 시계를 한 시간 앞당겨 +01:00 이 됩니다. 가을에는 다시 되돌립니다. 이렇게 여름철에 시계를 앞당기는 제도를 서머타임이라고 부릅니다.

오프셋은 한 순간의 차이를 적은 숫자일 뿐입니다. 타임존은 날짜마다 그 숫자를 정해 주는 규칙 전체입니다. 런던 타임존에는 Europe/London 이라는 이름이 붙습니다. 이 이름 하나가 겨울에는 +00:00, 여름에는 +01:00 을 내놓습니다.

아래 그림은 순간 하나를 런던의 지역 시각으로 바꾸는 순서입니다.

flowchart TD
    A["순간 · 7월의 UTC 12:00"] --> C["런던의 규칙에서 그날의 오프셋을 찾는다"]
    B["타임존 · Europe/London"] --> C
    C --> D["그날의 오프셋 · +01:00"]
    D --> E["지역 시각 · 13:00"]

순간과 타임존이 함께 들어가야 오프셋이 하나로 정해집니다. 같은 런던에 1월의 UTC 12:00 을 넣으면 오프셋은 +00:00 입니다. 지역 시각도 12:00 입니다.

타임존 이름

타임존 이름은 Asia/Seoul, Europe/London, America/New_York 처럼 생겼습니다. 앞은 대륙이나 대양입니다. 뒤는 그 지역을 대표하는 도시입니다. 나라 이름 대신 도시 이름을 쓰는 까닭은 나라 이름과 국경이 도시보다 자주 바뀌기 때문입니다.

이 이름들은 타임존 데이터베이스에서 왔습니다. 세계 각 지역의 타임존 규칙을 모아 둔 공개 자료입니다.

이 데이터베이스는 IANA(Internet Assigned Numbers Authority)가 펴냅니다. IANA 는 인터넷의 이름과 번호를 관리하는 기관입니다.

운영체제와 프로그래밍 언어의 런타임은 이 데이터베이스를 한 벌씩 들고 있습니다. 코드에 Asia/Seoul 이라고 적으면 런타임이 그 이름으로 규칙을 찾습니다.

도쿄의 Asia/Tokyo 도 서울과 같은 +09:00 을 씁니다. 그런데 둘은 다른 타임존입니다. 서울은 한때 여름마다 시계를 한 시간 앞당긴 해가 있었습니다. 도쿄는 그해에도 시계를 옮기지 않았습니다.

이처럼 타임존은 오프셋이 같은 지역끼리 묶은 것보다 잘게 나뉩니다. 서울과 도쿄는 +09:00 한 묶음이지만 타임존은 둘입니다. 지난 이력이 다르면 따로 두어야 옛 순간을 그때의 지역 시각으로 되살릴 수 있습니다. 그래서 오프셋만 보고는 어느 타임존인지 알 수 없습니다.

약어 대신 이름을 쓰는 까닭

일상에서는 KST 같은 세 글자 약어를 자주 봅니다. KST 는 한국 표준시(Korea Standard Time)의 줄임말입니다. 표준시는 서머타임을 적용하지 않은 그 지역의 기본 시각입니다.

약어는 여러 지역이 겹쳐 씁니다. CST 는 미국 중부 표준시(Central Standard Time)의 줄임말입니다. 그런데 중국 표준시(China Standard Time)도 CST 로 줄입니다. 겨울에 두 시각은 14시간 벌어집니다.

약어는 철마다 바뀌기도 합니다. 뉴욕은 겨울에 -05:00 인 EST(Eastern Standard Time, 동부 표준시)를 씁니다. 여름에는 -04:00 인 EDT(Eastern Daylight Time, 동부 서머타임)로 바뀝니다. 약어 하나는 한 철의 오프셋만 가리키는 셈입니다.

그래서 코드와 데이터에는 약어 대신 America/New_York 같은 이름을 적습니다. 이름은 하나의 지역을 가리킵니다. 철이 바뀌어도 이름은 그대로입니다.

바뀌는 규칙

타임존 규칙은 기술이 아니라 각 나라의 법이 정합니다. 앞에서 본 서울이 그 예입니다. 서울은 여름마다 시계를 앞당기던 제도를 그만두면서 규칙이 바뀌었습니다. 정부가 서머타임을 두거나 없애고 기준 오프셋을 옮길 때마다 이런 변경이 생깁니다.

타임존 데이터베이스는 이런 변경을 받아 새 판을 냅니다. 변경은 시행을 몇 주 앞두고 발표되기도 합니다.

운영체제나 런타임이 새 판을 받지 않으면 바뀐 지역의 시각을 옛 규칙으로 계산합니다. 런던이 서머타임을 그만두었는데 서버가 옛 판을 들고 있다면, 여름의 UTC 12:00 을 여전히 13:00 으로 보여 줍니다. 새 규칙으로는 12:00 이어야 하니 사용자에게 한 시간 어긋난 시각이 보입니다.

데이터베이스는 지난 규칙도 지우지 않습니다. 몇 년 전의 순간을 그때 그 지역 시각으로 바꾸려면 그때의 규칙이 필요하기 때문입니다.

없는 시각과 두 번 오는 시각

지역 시각을 순간으로 되돌릴 때는 시계를 옮기는 날이 함정입니다. 뉴욕에서 서머타임이 시작하는 날과 끝나는 날을 가지고 봅니다.

뉴욕은 서머타임이 시작하는 날 새벽 2시에 시계를 3시로 넘깁니다. 그날 2시 30분이라는 지역 시각은 존재하지 않습니다. 「그날 2시 30분에 실행」으로 잡은 작업은 어느 순간에 돌아야 할지 정해지지 않습니다.

서머타임이 끝나는 날에는 새벽 2시에 시계를 1시로 되돌립니다. 그래서 1시 30분이 두 번 옵니다. 앞의 것은 -04:00, 뒤의 것은 -05:00 입니다. 지역 시각만 적어 두면 둘 중 어느 순간인지 가릴 수 없습니다.

날짜·시각 라이브러리는 이런 경우에 한쪽을 골라 줍니다. 무엇을 고르는지는 라이브러리마다 다릅니다. 그래서 전환일 근처의 예약은 어느 쪽을 쓸지 코드에 밝혀 둡니다.

백엔드 코드에서 만나는 타임존

백엔드에서 타임존이 끼어드는 때는 대개 셋입니다. 이미 지난 일을 저장할 때, 사용자에게 보여 줄 때, 앞날의 일정을 잡을 때입니다. 셋은 저장하는 값이 다릅니다.

상황	저장하는 값	까닭
이미 지난 일의 시각	UTC 순간	값끼리 바로 견줄 수 있다
사용자에게 보여 줄 때	사용자의 타임존 이름	보여 주는 순간에 지역 시각으로 바꾼다
앞날의 일정	지역 시각과 타임존 이름	그사이 규칙이 바뀌어도 지역 시각이 지켜진다

주문 시각이나 로그 시각처럼 이미 지난 순간은 UTC 로 저장합니다. 그러면 어느 서버가 적었든 값끼리 바로 견줄 수 있습니다. 화면에 띄울 때 그 사용자의 타임존으로 바꿉니다.

앞날의 일정은 다릅니다. 「서울에서 내년 3월 2일 오전 9시 회의」를 지금 규칙으로 UTC 로 바꿔 저장했다고 해 봅시다. 그사이 규칙이 바뀌면 저장된 순간은 더는 오전 9시가 아닙니다. 그래서 지역 시각과 타임존 이름을 함께 저장합니다. 순간은 회의가 다가왔을 때 계산합니다.

자바의 날짜·시각 라이브러리로 적으면 아래와 같습니다. 같은 런던 타임존에 1월과 7월의 UTC 12:00 을 넣어 봅니다.

Java

var lon = ZoneId.of("Europe/London");
var jan = Instant.parse("2026-01-15T12:00:00Z");
var jul = Instant.parse("2026-07-15T12:00:00Z");

jan.atZone(lon);  // 12:00 +00:00
jul.atZone(lon);  // 13:00 +01:00

Instant 는 UTC 위의 한 순간입니다. ZoneId 는 타임존 이름을 담습니다. atZone 은 순간에 타임존을 씌워 지역 시각을 만듭니다. 같은 UTC 12:00 이 1월에는 12시로, 7월에는 13시로 나옵니다.

서버의 기본 타임존

코드가 타임존을 따로 주지 않으면 서버의 기본 타임존이 쓰입니다. 유닉스 계열 운영체제에서는 시스템 설정이나 TZ 환경 변수가 이 값을 정합니다. TZ 는 Time Zone 의 줄임말입니다.

개발자 노트북의 기본 타임존이 Asia/Seoul, 운영 서버는 UTC 라고 해 봅시다. 같은 코드가 노트북에서는 오전 9시를, 서버에서는 0시를 찍습니다. 테스트가 노트북에서만 통과하는 일이 이렇게 생깁니다.

그래서 지역 시각이 필요한 코드에는 타임존을 직접 넘깁니다. 서버의 기본 타임존을 UTC 로 고정해 두면 기본값에 기대는 코드가 있어도 서버마다 결과가 갈리지 않습니다.

상세

순간과 지역 시각

오프셋만으로는 모자라는 까닭

타임존 이름

약어 대신 이름을 쓰는 까닭

바뀌는 규칙

없는 시각과 두 번 오는 시각

백엔드 코드에서 만나는 타임존

서버의 기본 타임존

관련 항목

타임존이 속하는 상위 분류

타임존이 오프셋을 재는 기준 시각

타임존 규칙을 이루는 구성 요소

타임존 규칙을 모아 나르는 데이터베이스와 설정

타임존을 함께 담는 시각 자료형

타임존 없이 순간을 적는 표기

타임존 차이로 어긋나기 쉬운 작업