시간대 계산기

목표 지역 시각 = 출발 지역 시각 − 출발 지역 UTC 시차 + 목표 지역 UTC 시차; 시차의 차이 = 목표 지역 시차 − 출발 지역 시차; 날짜 변경 = 목표 날짜 − 출발 날짜

date

출발 지역의 날짜(YYYY-MM-DD). 내가 있는 곳의 날짜가 아니라 그쪽의 날짜입니다

time

출발 지역의 시각. 24시간제 HH:MM 또는 HH:MM:SS로 넣습니다. 초는 생략할 수 있지만 결과에는 항상 표시됩니다

fromZone

입력한 시각이 속한 시간대. IANA 시간대 22개 가운데 하나이며, 시차가 아니라 도시 이름으로 표시됩니다. 시차는 장소의 성질이 아니라 그 순간의 성질이기 때문입니다

toZone

변환할 대상 시간대. 출발 목록과 같은 22개입니다

toTime

목표 시간대의 시각. 항상 초까지 표시되며, 이 페이지의 대표 결과입니다

toDate

목표 시간대의 날짜. 입력한 날짜와 늘 같지는 않으며, 그것이 날짜 변경이라는 항목이 필요한 이유입니다

toWeekday

목표 시간대의 요일. 일요일을 0으로 하는 0–6의 숫자로 주어집니다

fromOffset

해석된 순간에 출발 시간대가 UTC에서 얼마나 떨어져 있는지. UTC±HH:MM으로 표시됩니다

toOffset

같은 순간에 목표 시간대가 UTC에서 얼마나 떨어져 있는지. 두 시차 모두 변환된 순간을 기준으로 읽으므로, 그곳에 서머타임이 시행 중이라면 둘 다 서머타임이 반영됩니다

offsetDifference

목표 시차에서 출발 시차를 뺀 값(시간). 음수면 목표가 출발보다 뒤에 있습니다

dayShift

−1, 0, +1 가운데 하나. 목표 날짜가 입력한 날짜의 전날인지, 같은 날인지, 다음 날인지를 나타냅니다

두 곳이 얽힌 일정을 잡을 때 씁니다. 대륙을 넘는 통화 약속, 출발한 날과 같은 날 도착하는지 확인해야 하는 항공편, UTC로 적힌 서버 로그를 읽을 때, 친구가 말한 일요일 아침이 내 일요일 저녁인 이유를 따질 때 모두 이 페이지로 시작합니다. 손으로 계산할 때 가장 자주 틀리는 것이 날짜 변경입니다. 두 도시의 시차는 두 도시에 고정된 성질이 아니라서, 같은 두 곳이 계절에 따라 한 시간씩 달라지기 때문입니다. 예를 들어 서울과 뉴욕은 1월에 14시간, 7월에 13시간 차이가 납니다. 한국은 1988년을 마지막으로 서머타임을 시행하지 않으므로 KST(UTC+9)가 연중 고정입니다. 그래서 서울과 다른 도시의 시차는 그 도시가 서머타임을 쓰는 동안에만 한 시간 달라집니다. 다만 이 페이지는 이미 가지고 있는 한 순간을 변환할 뿐, 어떤 지명이 어느 시간대인지 알려 주지는 않습니다. 목록이 22개로 고정되어 있기 때문입니다. 이동 시간이나 비행 시간, 약속 알림도 다루지 않습니다.

1. 상하이 정오에서 뉴욕으로 — 하루 전

   1. 상하이는 1월에 UTC+08:00이므로, 그곳의 정오는 1월 15일 04:00 UTC입니다
   2. 뉴욕은 EST, 즉 UTC−05:00이므로 04:00 UTC는 그쪽 시계로 23:00입니다
   3. 23:00은 자정을 넘지 못했으므로 날짜가 1월 14일로 내려갑니다. 입력한 날짜보다 하루 앞이고, 날짜 변경이 −1로 나옵니다
   4. 2026년 1월 14일은 수요일이므로 요일 숫자는 3입니다
   5. 두 시차의 차이는 −13시간입니다. 08:00 − (−05:00)은 13시간이고, 목표 쪽이 더 서쪽에 있습니다

   이 계산기의 기본 상태이고, 사람들이 가장 놀라는 경우입니다. 상하이에서 점심때 보낸 메시지가 뉴욕에는 전날 도착합니다. 상하이가 12시간이나 13시간 앞선다는 한 가지 규칙으로 손으로 계산하면 여기서 틀어집니다. 지금 답은 13이지만 7월에는 12가 됩니다. 뉴욕은 서머타임을 쓰고 상하이는 쓰지 않기 때문입니다.

2. 존재하지 않는 시각: 2026년 3월 8일 뉴욕 02:30

   1. 이날 뉴욕은 현지 시각 02:00에 시계를 한 시간 앞으로 당기므로, 02:00이 03:00이 되고 02:00에서 03:00 사이의 30분은 아예 일어나지 않습니다
   2. 따라서 입력한 02:30은 존재하지 않습니다. 이 페이지는 IANA 규칙이 빈 구간에 대해 정한 대로 그 시각을 앞으로 밀어, 03:30 EDT로 읽습니다
   3. 2026년 3월 8일 03:30은 일요일이므로 요일 숫자는 0입니다
   4. 해석된 순간이 이미 EDT에 있으므로 표시되는 출발 시차는 UTC−04:00입니다. 하루 전이라면 02:30이 지녔을 UTC−05:00이 아닙니다
   5. 상하이는 UTC+08:00으로 EDT보다 12시간 앞서므로, 03:30은 같은 날 15:30이 됩니다

   입력한 시각 옆에 붙는 시차는 이유를 알고 나면 납득이 갑니다. 겨울의 뉴욕 02:30은 UTC−05:00의 시계 읽기지만, 이 02:30은 시계를 당긴 직후의 빈 구간에 떨어지므로 해석되는 순간은 EDT의 것이 되고 UTC−04:00으로 보고됩니다. 이 페이지는 빈 구간과 겹치는 구간을 IANA 시간대 데이터베이스가 정한 방식으로 읽고 입력을 거부하지 않습니다. 그래서 값은 항상 나오고, 이 예는 두 번 읽어 볼 만합니다.

3. 양쪽 모두 서머타임인 날: 7월 4일 런던에서 로스앤젤레스로

   1. 7월의 런던은 BST, 즉 UTC+01:00이므로 그곳의 09:30은 08:30 UTC입니다
   2. 로스앤젤레스는 PDT, 즉 UTC−07:00이므로 08:30 UTC는 그쪽 시계로 01:30입니다
   3. 두 시차의 차이는 8시간입니다. 겨울에 사람들이 기대하는 8시간과 숫자는 같지만 서로 다른 8입니다. 1월이라면 런던은 UTC+00:00, 로스앤젤레스는 UTC−08:00입니다
   4. 표시되는 두 시차 모두 각자의 서머타임을 반영하므로, 출발 쪽이 UTC+00:00이 아니라 UTC+01:00으로 나옵니다
   5. 날짜는 그대로이므로 날짜 변경은 0이고, 2026년 7월 4일은 토요일이라 요일 숫자는 6입니다

   표준 시차인 0과 −08:00으로 답해도 같은 8시간 차이와 같은 시각이 나옵니다. 그래서 여기서는 오류를 알아채기 어렵고, 대신 전환이 있는 날 앞뒤에서 드러납니다. 3월의 같은 주에 두 시간대가 서로 반대 방향으로 시계를 움직이는 것이 고정 시차 규칙이 한 시간씩 틀어지는 지점입니다.

4. 오클랜드의 새해, UTC로는 아직 지난해

   1. 1월의 오클랜드는 NZDT, 즉 UTC+13:00이므로 그곳의 자정은 2025년 12월 31일 11:00 UTC입니다
   2. 따라서 UTC로 바꾸면 날짜 경계와 연도 경계를 한꺼번에 넘습니다
   3. 목표 날짜는 2025년 12월 31일이고, 날짜 변경 −1은 날짜 문자열을 비교한 것이 아니라 날짜 번호를 빼서 구합니다
   4. 2025년 12월 31일은 수요일이므로 요일 숫자는 3입니다
   5. 시차의 차이는 −13시간입니다. 목표인 UTC가 더 서쪽에 있습니다

   날짜 변경은 단순히 서쪽이 어제라는 규칙이 아닙니다. 여기서는 −13시간이 자정을 넘겼고, 상하이와 뉴욕 사이의 같은 −13시간도 전날로 떨어지지만 런던에서 뉴욕으로 가는 −5시간은 그렇지 않습니다. 요일은 목표 날짜의 것으로 보고되므로, 입력한 날짜가 목요일인데 결과는 수요일이라고 나옵니다.

이 계산기는 1970년부터 2100년까지, 그리고 IANA 데이터베이스가 아는 모든 시간대가 아니라 22개의 시간대를 다룹니다. 범위를 이렇게 잡은 것은 의도적입니다. 1970년 이전에 데이터베이스가 기록해 둔 것은 그 지역이 실제로 쓰던 지역 평균시여서, 상하이는 UTC+08:06이었고 어떤 도시는 초 단위가 붙은 시차를 썼습니다. 그런 답은 정확하지만 오류로 읽힙니다. 빈 구간과 겹치는 구간은 IANA 규칙대로 처리하고 거부하지 않습니다. 봄에 시계를 당기는 빈 구간은 앞으로 밀고, 가을에 겹치는 구간은 앞선 쪽을 택합니다. 다만 그런 일이 일어났다고 알려 주지는 않으므로, 전환이 있는 날 앞뒤의 날짜는 표시된 시차와 함께 확인해 보시기 바랍니다. 입력한 지명에서 시간대를 추정하지도 않습니다. 입력할 곳이 없기 때문입니다. 두 목록 모두 고정되어 있습니다. 이 페이지는 사용자의 기기가 어느 시간대에 있는지도 모르고, 소요 시간이나 비행 시간을 계산하지 않으며, 윤초도 넣지 않습니다. 시간대 변환은 윤초와 무관하게 이루어집니다.

두 도시의 시차는 얼마인가요?

도시 사이의 시차는 고정된 값이 아니고, 이 페이지가 보여 주는 시차는 입력한 날짜에 실제로 시행되는 값입니다. 한쪽이 서머타임을 쓰고 다른 쪽이 쓰지 않으면 두 곳이 1월에 14시간, 7월에 13시간 차이가 날 수 있습니다. 그래서 시차 계산에는 날짜가 함께 붙어야 하고, 이 페이지에서 날짜 입력이 선택 항목이 아니라 질문의 일부인 이유도 여기에 있습니다.

여러 시간대에 걸친 회의 시간은 어떻게 정하나요?

회의가 제안된 시간대를 기준으로 시각을 넣고, 나머지 시간대로 차례로 변환합니다. 시차를 넘는 회의에서 쓸모 있는 숫자는 보통 시각이 아니라 날짜 변경입니다. 겨울 기준으로 런던 09:00은 도쿄에서 같은 날 18:00이지만 뉴욕에서는 04:00이고, 초대장이 무리인지를 가르는 것은 그 04:00입니다. 요일과 날짜도 함께 나오므로 제안한 시간이 상대방의 주말로 떨어지는지도 바로 보입니다.

서머타임은 자동으로 적용되나요?

네, 두 시간대 모두에, 그리고 오늘이 아니라 입력한 날짜를 기준으로 적용됩니다. 서머타임은 시간대의 성질이 아니라 순간의 성질입니다. 표시되는 시차는 변환하는 순간에 대해 IANA 규칙이 주는 값이므로, 같은 두 도시라도 1월과 7월에 한 시간 차이가 날 수 있습니다. 현재 날짜를 가정하지 않으므로 다음 3월의 전환도 이미 반영되어 있습니다. 다만 한국은 1988년을 마지막으로 서머타임을 시행하지 않아 KST(UTC+9)가 연중 고정입니다. 1987년과 1988년에는 한국도 시행했으므로, 그 시기의 여름 날짜를 넣으면 서울이 UTC+10:00으로 나옵니다.

UTC 시차가 생각했던 값과 다른 이유는 무엇인가요?

표시되는 시차는 입력한 시각이 아니라 그 입력이 해석된 순간의 것입니다. 시계를 앞으로 당기는 날에는 건너뛴 한 시간이 존재하지 않고, 그 안에 넣은 시각은 그 직후의 순간으로 읽힙니다. 그래서 3월 전환일의 뉴욕 02:30은 UTC−05:00이 아니라 UTC−04:00으로 보고됩니다. 두 값은 같은 순간을 가리키고, 그 순간에 실제로 시행되는 시차는 하나뿐입니다.

여기가 수요일이면 그쪽은 무슨 요일인가요?

시차와 시각이 함께 정하므로, 이 페이지가 두 가지를 함께 묻습니다. 13시간 앞선 곳으로 옮기면 시각에 따라 날짜가 하루 넘어가기도 하고 그대로이기도 합니다. 날짜 변경 항목이 −1, 0, +1로 그것을 바로 답하고, 요일 항목이 도착지의 요일을 알려 주므로 상대방이 물어본 그날에 이미 들어섰는지도 알 수 있습니다.

• IANA Time Zone Database — IANA가 관리하는 시간대 데이터베이스 — Internet Assigned Numbers Authority
• Theory and pragmatics of the tz code and data — 이 페이지가 밝히는 1970-01-01 기준 범위의 근거 — IANA
• Temporal documentation, Time zone handling — 이 페이지가 따르는 호환 방식의 설명 — TC39