사용 방법과 결과 읽는 법
기준 도시를 고르고 그 도시의 벽시계 기준 날짜·시각을 입력한 뒤 "변환하기"를 누르면, 같은 순간을 다른 도시의 현지 시각으로 환산합니다. 각 줄에는 현지 날짜·요일·시각, 그 시점의 UTC 오프셋, 기준 도시와 날짜가 다르면 "전날/다음날" 표시, 서머타임(일광절약시간) 적용 중이면 표시가 붙습니다. 입력란을 비우면 현재 시각을 기준 도시의 시각으로 간주합니다. 의도한 시각을 정확히 보려면 입력값이 "내 컴퓨터 시각"이 아니라 "기준 도시의 시각"이라는 점을 기억하세요. 서울에서 뉴욕 회의를 잡을 때 기준 도시를 서울로 두고 서울 시각을 넣으면 됩니다.
시차 계산의 원리
모든 지역 시각은 협정 세계시(UTC)에 일정한 오프셋을 더한 값입니다. 서울은 UTC+9, 런던의 겨울은 UTC+0, 뉴욕의 겨울은 UTC-5입니다. 서울 시각에서 뉴욕 시각으로 바꾸는 계산은 다음 세 단계입니다.
- 기준 도시 시각에서 그 도시의 오프셋을 빼서 UTC 시각을 구합니다. (서울 09:00 − 9시간 = UTC 00:00)
- UTC 시각에 목적지 도시의 오프셋을 더합니다. (UTC 00:00 + (−5시간) = 전날 19:00)
- 날짜가 넘어가면 날짜도 함께 바꿉니다.
문제는 같은 도시의 오프셋이 일 년 내내 같지 않다는 것입니다. 이 변환기는 입력한 날짜 그 순간의 오프셋을 시간대 데이터베이스(IANA)에서 조회해 쓰므로 서머타임 전환 전후를 따로 신경 쓰지 않아도 되지만, 아래 표의 시차는 날짜에 따라 달라진다는 점을 이해해야 합니다.
도시별 UTC 오프셋과 서울 기준 시차 (참고표)
아래 표는 이 페이지가 만들어질 때 시간대 데이터베이스로 계산한 값으로, 2026년 1월 15일과 7월 15일 두 날짜를 기준으로 합니다. 서머타임 규정은 국가가 바꿀 수 있으므로 실제 일정이 중요하면 해당 국가·기관의 공지나 최신 시간대 정보로 한 번 더 확인하세요.
| 도시 | 1월 15일 | 7월 15일 | 서울과 시차(1월) | 서울과 시차(7월) | 서머타임 |
|---|---|---|---|---|---|
| 서울 | UTC+9 | UTC+9 | 0 | 0 | 없음 |
| 도쿄 | UTC+9 | UTC+9 | 0 | 0 | 없음 |
| 베이징 | UTC+8 | UTC+8 | -1 | -1 | 없음 |
| 방콕 | UTC+7 | UTC+7 | -2 | -2 | 없음 |
| 뉴델리 | UTC+5:30 | UTC+5:30 | -3.5 | -3.5 | 없음 |
| 두바이 | UTC+4 | UTC+4 | -5 | -5 | 없음 |
| 런던 | UTC+0 | UTC+1 | -9 | -8 | 있음 |
| 파리 | UTC+1 | UTC+2 | -8 | -7 | 있음 |
| 뉴욕 | UTC-5 | UTC-4 | -14 | -13 | 있음 |
| 로스앤젤레스 | UTC-8 | UTC-7 | -17 | -16 | 있음 |
| 시드니 | UTC+11 | UTC+10 | +2 | +1 | 있음 |
시차 열의 숫자는 "해당 도시 시각 − 서울 시각"(시간 단위)입니다. 예를 들어 뉴욕의 1월 값이 −14라면 서울이 정오일 때 뉴욕은 전날 22:00이라는 뜻입니다. 시드니는 남반구라서 서머타임이 한국의 겨울(1월)에 적용되는 점이 눈에 띕니다. 뉴델리는 UTC+5:30처럼 30분 단위 오프셋을 쓰므로 정시 단위 계산이 아닙니다.
검산한 계산 예시
예시 1. 서울 2026-03-10 09:00은 UTC 00:00이고, 그때 뉴욕은 2026-03-09 20:00, 런던은 2026-03-10 00:00입니다. 미국은 2026년 3월 8일에 서머타임이 시작되어 뉴욕이 UTC−4가 된 반면 런던은 아직 UTC+0이라, 같은 3월이라도 1월보다 뉴욕과 서울의 시차가 1시간 줄었습니다.
예시 2. 런던 2026-01-20 15:00은 UTC 15:00이고 서울은 UTC+9이므로 2026-01-21 00:00(다음 날 자정)입니다.
예시 3. 서울 2026-07-01 12:00은 UTC 03:00입니다. 이때 시드니(UTC+10)는 같은 날 13:00, 로스앤젤레스(UTC−7)는 전날인 2026-06-30 20:00입니다.
자주 하는 실수와 한계
- 서머타임 전환 주간의 어긋남: 미국·유럽·호주의 서머타임 시작·종료일이 서로 다르기 때문에, 몇 주 동안은 평소와 시차가 1시간 달라집니다. 정기 회의를 연중 같은 서울 시각에 잡으면 상대방에게는 한 시간씩 밀려 보일 수 있습니다.
- 존재하지 않는 시각과 겹치는 시각: 서머타임이 시작되는 날 건너뛰는 한 시간(예: 02:00~03:00)과 종료되는 날 두 번 나타나는 한 시간은 지역 시각 하나로 순간이 확정되지 않습니다. 이 구간을 입력하면 한 가지로 해석되므로 중요한 일정이면 전환일 전후는 피하거나 UTC로 확인하세요.
- 도시와 시간대의 차이: 한 나라가 여러 시간대를 쓰는 경우(미국, 호주 등)가 있습니다. 이 도구의 도시는 대표 도시일 뿐 같은 나라의 다른 지역에는 맞지 않을 수 있습니다.
- 이 도구의 범위: 11개 도시만 제공하며, 규정이 바뀐 과거·미래 날짜는 브라우저에 내장된 데이터 버전에 따라 결과가 다를 수 있습니다. 항공권·계약·법적 기한처럼 정확성이 중요한 용도에는 공식 일정표와 함께 확인해 주세요.
- 한국의 서머타임: 한국은 현재 서머타임을 시행하지 않아 연중 UTC+9입니다. 과거에 시행한 시기가 있어 아주 오래전 날짜는 데이터베이스가 다른 오프셋을 줄 수 있습니다.
서울 업무시간과 겹치는 도시는 어디인가
서울의 근무 시간을 09:00~18:00으로 가정하고, 각 도시의 같은 시간대(현지 09:00~18:00) 근무가 서울 시각으로는 언제인지 계산한 표입니다. 겹침은 두 도시의 근무 시간이 동시에 걸리는 시간(시간 단위)이며, 2026년 1월 15일과 7월 15일의 오프셋으로 빌드 시 계산했습니다.
| 도시 | 현지 근무 = 서울 시각(1월) | 겹침(1월) | 현지 근무 = 서울 시각(7월) | 겹침(7월) |
|---|---|---|---|---|
| 도쿄 | 09:00~18:00 | 9시간 | 09:00~18:00 | 9시간 |
| 베이징 | 10:00~19:00 | 8시간 | 10:00~19:00 | 8시간 |
| 방콕 | 11:00~20:00 | 7시간 | 11:00~20:00 | 7시간 |
| 뉴델리 | 12:30~21:30 | 5.5시간 | 12:30~21:30 | 5.5시간 |
| 두바이 | 14:00~23:00 | 4시간 | 14:00~23:00 | 4시간 |
| 런던 | 18:00~03:00 | 0시간 | 17:00~02:00 | 1시간 |
| 파리 | 17:00~02:00 | 1시간 | 16:00~01:00 | 2시간 |
| 뉴욕 | 23:00~08:00 | 0시간 | 22:00~07:00 | 0시간 |
| 로스앤젤레스 | 02:00~11:00 | 2시간 | 01:00~10:00 | 1시간 |
| 시드니 | 07:00~16:00 | 7시간 | 08:00~17:00 | 8시간 |
아시아 도시(도쿄·베이징·방콕)는 서울과 근무 시간이 대부분 겹치지만, 런던·파리·뉴욕은 서울의 늦은 저녁이나 새벽에야 현지 근무 시간이 시작됩니다. 표에서 겹침이 0~2시간인 도시와는 한쪽이 업무 시간 밖으로 나오는 회의를 감수해야 하며, 이 경우 매번 같은 사람이 불리하지 않도록 번갈아 시각을 정하는 방식이 흔히 쓰입니다. 시드니는 서머타임이 반대 계절에 걸려 1월과 7월의 겹침이 한 시간 달라집니다.
2026년 서머타임 전환일
표의 시차가 계절마다 달라지는 이유가 되는 전환 시점입니다. 이 페이지가 만들어질 때 시간대 데이터베이스를 하루 단위로 훑어 오프셋이 바뀐 날을 찾은 결과이며, 날짜는 해당 도시의 현지 날짜 기준입니다. 규정이 바뀌면 실제와 달라질 수 있으니 중요한 일정은 공식 공지로 다시 확인하세요.
| 도시 | 2026년 전환(순서대로) |
|---|---|
| 런던 | 3월 29일 (일) 전후(UTC+0 → UTC+1), 10월 25일 (일) 전후(UTC+1 → UTC+0) |
| 파리 | 3월 29일 (일) 전후(UTC+1 → UTC+2), 10월 25일 (일) 전후(UTC+2 → UTC+1) |
| 뉴욕 | 3월 8일 (일) 전후(UTC-5 → UTC-4), 11월 1일 (일) 전후(UTC-4 → UTC-5) |
| 로스앤젤레스 | 3월 8일 (일) 전후(UTC-8 → UTC-7), 11월 1일 (일) 전후(UTC-7 → UTC-8) |
| 시드니 | 4월 5일 (일) 전후(UTC+11 → UTC+10), 10월 4일 (일) 전후(UTC+10 → UTC+11) |
미국(뉴욕·로스앤젤레스)과 유럽(런던·파리)의 전환일이 서로 달라서, 3월 8일부터 3월 29일 사이의 몇 주 동안은 뉴욕과 런던의 시차가 평소 5시간에서 4시간으로 줄어듭니다. 가을에도 10월 25일부터 11월 1일 사이에 비슷한 어긋남이 생깁니다. 이 기간에 미국과 유럽이 함께 참여하는 정기 회의를 잡았다면 한 주 전에 각자의 현지 시각을 다시 확인하는 편이 안전합니다.
시나리오: 서울-런던-뉴욕 3자 회의 잡기
서울 팀장이 런던 지사와 뉴욕 지사를 한 번에 부르는 회의를 잡는 상황을 가정합니다. 1월에는 서울 22:00이 UTC 13:00이므로 런던은 13:00, 뉴욕은 08:00입니다. 서울 입장에서는 늦은 밤이지만 뉴욕은 막 출근하는 시간이라, 셋이 모두 업무 시간 안에 들어오는 슬롯은 없습니다. 서울 21:00(런던 12:00, 뉴욕 07:00)도 뉴욕이 아침 이른 시간이라 부담이 큽니다. 이럴 때는 이 변환기에서 기준 도시를 서울로 두고 시각을 21:00, 22:00, 23:00으로 바꿔 가며 세 도시의 줄을 비교하고, 가장 덜 불편한 후보를 고른 뒤 "결과 복사"로 참석자에게 공유하세요. 모든 사람이 업무 시간에 들어오는 시간이 없다면 비동기 공유(문서·녹화)로 대체하는 선택도 있습니다.
시간을 공유할 때 쓰는 표기 요령
- UTC 오프셋을 같이 적습니다. "오후 3시"만 쓰면 어느 도시 기준인지 모호하므로 "서울 15:00(UTC+9)"처럼 도시와 오프셋을 함께 쓰는 것이 안전합니다.
- 24시간제를 권합니다. 이 도구의 결과는 오전/오후 표기이지만, 국가 간 공유 문서는 14:00 같은 24시간제가 혼동이 적습니다.
- 날짜 변경을 명시합니다. 서울 월요일 오전 9시가 뉴욕에서는 일요일 저녁이 될 수 있으니 요일까지 함께 쓰세요.
- 자정 부근은 피합니다. 00:00 전후는 날짜 경계라 서로 다른 날짜로 이해하는 사고가 가장 잦습니다.
결과를 활용하는 방법
- 여러 지역 참석자가 있는 회의라면 모든 참석자의 현지 시각이 업무 시간대(예: 08:00~20:00)에 들어오는지 확인하고, 벗어나는 사람이 한 명이라도 있으면 시각을 한 시간씩 옮겨 가며 다시 변환합니다.
- "결과 복사"로 나온 줄을 메신저·메일에 붙여 넣으면, 상대가 자기 도시 시각을 직접 계산하지 않아도 됩니다. 날짜가 바뀌는 도시에는 요일까지 함께 적혀 있어 착오를 줄입니다.
- 여행·해외 직구·해외 라이브 방송 시청처럼 일회성 일정은 날짜까지 넣어 그날의 오프셋 기준으로 보고, 정기 일정은 서머타임 전환 시기 전후를 따로 한 번 더 확인하세요.
자주 묻는 질문
서머타임(DST)도 반영되나요?
네. 브라우저에 내장된 시간대 데이터베이스를 사용하기 때문에, 입력한 날짜에 해당 도시가 서머타임을 적용 중인지 자동으로 계산에 반영되고 결과 줄에도 표시됩니다. 다만 전환일 당일 새벽 시간대는 위의 "존재하지 않는 시각" 문제가 있습니다.
기준 시각을 입력하지 않으면 어떻게 되나요?
비워두면 변환 시점의 현재 시각을 기준 도시의 시각으로 보고 계산합니다. 기준 도시를 서울이 아닌 곳으로 바꿨는데 입력을 비워 두면 "지금 내 컴퓨터 시각"이 그 도시의 시각이라고 가정하므로, 실제 그 도시의 현재 시각을 알고 싶다면 서울로 두거나 값을 직접 입력하세요.
왜 같은 도시인데 날짜에 따라 시차가 달라지나요?
서머타임 때문입니다. 서머타임이 있는 나라는 일 년 중 일부 기간 시계를 1시간 앞당기고, 서머타임이 없는 한국은 그대로이므로 시차가 계절마다 1시간씩 달라집니다.
UTC와 GMT는 같은가요?
일상에서는 거의 같은 값으로 쓰이지만 엄밀히는 다릅니다. GMT는 영국 그리니치를 기준으로 한 평균 태양시에서 출발했고, UTC는 원자시계를 기반으로 하는 국제 표준 시각입니다. 영국의 겨울 시간대를 GMT라고 부르고, 여름에는 BST(UTC+1)를 씁니다.
뉴델리 같은 지역은 왜 30분 단위인가요?
일부 국가는 정시 간격이 아닌 UTC+5:30 같은 오프셋을 국가 표준시로 정했기 때문입니다. 이 변환기는 시간대 데이터베이스의 값을 그대로 쓰므로 분 단위 오프셋도 정확히 계산합니다.
입력한 시각이 서버로 전송되나요?
아니요. 계산은 모두 브라우저 안에서 이루어지고 입력값은 저장되거나 전송되지 않습니다. 결과 복사도 사용자의 클립보드로만 보내집니다.
시드니는 왜 1월에 서울과의 시차가 더 큰가요?
시드니는 남반구라서 1월이 여름이고 서머타임(UTC+11)이 적용됩니다. 그래서 서울(UTC+9)과의 시차가 +2시간으로 7월(UTC+10, 시차 +1시간)보다 큽니다.
이 변환기에 없는 도시는 어떻게 계산하나요?
해당 도시의 UTC 오프셋을 알면 위 3단계 공식으로 직접 계산할 수 있습니다. 더 많은 도시가 필요하면 아래 확장판 변환기를 이용하세요. 도시의 서머타임 여부는 공식 공지나 시간대 데이터베이스 이름(예: America/Chicago)으로 확인하는 것이 확실합니다.