01
기기 설정을 지역과 혼동하지 않기
기기 시간대 버튼은 위치를 조회하지 않고 브라우저 설정을 읽습니다. UTC나 기기 시간대로 기준을 바꾸면 숫자는 그대로 다시 해석됩니다. 기존 순간을 유지하는 작업이 아니므로 미리보기를 확인하세요.
날짜와 시간
시간대 변환기한 순간을 여러 지역의 시계로
기준 지역의 날짜와 시간을 입력하고 대상 IANA ID를 한 줄씩 적어 비교하세요.
시간대 변환기
기준 시각
YYYY-MM-DDTHH:mm[:ss] 형식입니다. T 대신 공백도 가능합니다. Z, 오프셋, 소수 초는 넣지 않습니다.
UTC 또는 Asia/Seoul 같은 IANA ID를 입력하세요. 기준 시간대를 바꾸면 같은 시계 숫자를 새 지역의 시각으로 해석합니다.
한 줄에 ID 하나. 최대 20개 실제 줄, 2,000자입니다. 빈 줄은 건너뛰고 같은 ID는 한 번만 표시합니다.
지역별 시간 비교
기준 시각을 입력하거나 예시를 불러오세요.
날짜는 이 브라우저에서 처리하며 서버로 전송하지 않습니다.
설정
시간대 데이터와 실행 환경
엔진: @js-temporal/polyfill 0.5.1 및 브라우저 Intl 데이터. 브라우저는 시간대 데이터베이스 버전을 공개하지 않습니다. 미래 규칙은 바뀔 수 있습니다.
브라우저에서 확인한 시간대: 확인할 수 없음
입력이 바뀌었습니다. 복사하거나 다운로드하기 전에 다시 계산하세요.
시간대 변환기는 해외 회의나 서비스 점검 시각을 국내 일정에 옮길 때 유용합니다. 미국과 유럽은 시계를 바꾸는 날짜가 달라서 평소 기억하던 시차가 특정 주에는 맞지 않을 수 있습니다.
서울에서 자정을 넘긴 순간에도 다른 지역은 전날일 수 있습니다. 시각만 전달하지 말고 결과에 나온 날짜와 시간대를 함께 확인하세요.
시간대 변환기로 확인할 차이
날짜와 시계를 함께 비교
시간대 변환기는 각 지역의 현지 시각, 날짜, UTC 오프셋을 묶어 보여 줍니다. 기준 지역과의 차이는 별도로 계산하므로 UTC 기준으로 다섯 시간 늦다는 뜻을 서울보다 다섯 시간 늦다는 뜻으로 오해하지 않습니다.
같은 시각이 두 번일 때 구분
뉴욕의 2024년 11월 3일 01:30은 05:30Z와 06:30Z 중 하나입니다. 기본값은 모호한 입력을 거부하고 두 후보를 보여 줍니다. 첫 번째인지 두 번째인지 선택해야 같은 사건의 순간을 비교할 수 있습니다.
기준 지역과 반복 시각을 먼저 확인
02
누락 시각은 입력을 수정
첫 번째와 두 번째 선택은 시간이 겹치는 구간에서만 의미가 있습니다. 봄에 건너뛴 시각은 어느 쪽을 골라도 오류입니다. 원래 일정의 날짜와 오프셋을 확인하고 존재하는 시각을 입력해야 합니다.
03
수정 뒤 새 결과로 내보내기
자동 변환은 입력 후 350ms 기다립니다. 끄면 변환 버튼이나 Ctrl/Cmd + Enter를 사용합니다. 수정 즉시 내보내기가 잠기며 예시·초기화는 미리보기 후 적용합니다. 실행 취소는 입력과 결과를 함께 복원합니다.
날짜별 시차 계산과 여러 지역 비교
해당 날짜의 규칙 적용
2024년 3월 20일 뉴욕 09:00은 런던 13:00입니다. 미국이 먼저 서머타임에 들어간 시기라 차이는 네 시간입니다. 오늘의 오프셋을 모든 날짜에 그대로 쓰지 않습니다.
목록 순서대로 대상 출력
기본 대상은 런던, 뉴욕, 도쿄입니다. 줄을 추가하거나 지워 원하는 비교를 만드세요. 잘못된 ID가 있으면 실제 줄 번호를 알려 주고 변환 전체를 중단하여 일부만 있는 보고서가 만들어지지 않게 합니다.
오프셋과 지역 간 차이를 분리
UTC 오프셋의 기준은 UTC입니다. 지역 간 시차는 대상 오프셋에서 기준 오프셋을 뺀 값이며, 양수면 대상 시계가 앞섭니다. 날짜 변경선을 사이에 두면 24시간보다 클 수 있습니다.
분과 초 단위 차이 유지
Asia/Kathmandu의 45분과 Australia/Lord_Howe의 30분 전환을 처리합니다. 과거 데이터에 초 단위 오프셋이 있으면 그 값도 유지합니다. 모든 지역을 정수 시간대로 반올림하지 않습니다.
허용 형식과 데이터의 한계
- 오프셋 없는 날짜와 시간
- YYYY-MM-DDTHH:mm[:ss]에서 초를 생략하면 00입니다. T 대신 공백 하나도 허용합니다. 모든 결과 연도는 0001–9999입니다. 날짜만 있는 값, Z, 숫자 오프셋, 소수 초, 윤초, 24:00은 거부합니다.
- 약어 대신 지역 ID
- UTC 또는 /를 포함하는 지원 IANA ID를 사용합니다. CST·EST·IST나 +08:00만 입력하면 거부합니다. Etc/GMT+5는 IANA의 부호 규칙을 따릅니다. 서로 다른 이름의 별칭은 자동으로 같은 행에 합치지 않습니다.
- 없는 시각을 자동 보정하지 않음
- 첫 번째·두 번째 선택은 중복 시각에만 적용됩니다. 시계가 건너뛴 한 시간, 반 시간, 하루는 모두 오류입니다. 오프셋만 보고 서머타임 여부를 추정하는 배지도 제공하지 않습니다.
- 목록 크기와 정리 규칙
- 실제 20줄, 2,000자까지 받습니다. 빈 줄도 제한에는 포함되지만 결과에서는 생략합니다. 같은 ID는 대소문자를 무시하고 처음 나온 위치만 유지합니다. 도시 한글명 검색과 파일 가져오기는 지원하지 않습니다.
- 환경 데이터로 한 시점만 비교
- 브라우저의 시간대 데이터베이스 버전은 공개되지 않습니다. 엔진 버전은 IANA 데이터 버전이 아니며 미래 정책은 변경될 수 있습니다. 회의 시간 추천, 근무시간 판단, ICS 초대, 기록 저장과 공유 URL은 만들지 않습니다.
시간대 변환기 질문
서머타임(일광절약시간)도 반영되나요?
선택한 날짜에 해당하는 브라우저 IANA 규칙을 적용합니다. 기준 현지 시각이 반복되면 명시적인 선택이 필요하고 누락되면 거부합니다. 이미 정해진 UTC 순간을 대상 지역에 표시할 때는 다시 선택할 필요가 없습니다.
시간은 어떤 형식으로 입력하나요?
2024-03-20T09:00 또는 2024-03-20 09:00:00처럼 입력합니다. 시간대는 별도 칸에 쓰며 날짜 뒤에 Z나 +09:00을 붙이지 않습니다. 초를 생략하면 00으로 처리하고 소수 초는 받지 않습니다.
30분 단위 시간대는 왜 나오나요?
지역이 반드시 정수 시간 오프셋을 쓰는 것은 아닙니다. 일부는 30분, 네팔은 45분 성분을 사용합니다. 실제 데이터의 분과 초를 그대로 계산하므로 정수 시간만 표시하는 계산과 결과가 다를 수 있습니다.
두 도시의 시차가 한 해 동안 바뀌는 이유는 무엇인가요?
각 지역의 서머타임 적용 여부와 전환 날짜가 다르기 때문입니다. 두 도시가 모두 계절 전환을 하더라도 같은 날에 하지는 않을 수 있습니다. 실제 일정 날짜를 넣고 그날의 두 오프셋을 비교하세요.
어떤 시간대끼리 변환할 수 있나요?
브라우저가 인식하는 UTC 및 /가 포함된 IANA ID 사이에서 변환합니다. 예를 들면 Asia/Seoul, America/New_York, Europe/London입니다. 도시의 일반 이름이나 시간대 약어를 자동 해석하지는 않습니다.
계산 결과를 더 살펴봐야 하나요?
다음 일정도 날짜와 함께 확인
시간대 변환기에서 기준 지역과 이벤트 날짜를 확인한 뒤 결과를 전달하세요. UTC 순간과 현지 날짜를 같이 남기면 상대방도 같은 시간을 검증할 수 있습니다.