모든 처리는 브라우저 내부에서 실행됩니다 — 파일·입력은 서버로 전송되지 않습니다.
도시를 목록에 추가하세요(서울·도쿄·뉴욕·런던·샌프란시스코 — 동료가 있는 곳 등). 각 도시의 현재 시각이 라이브로 표시되고, 상단의 타임 슬라이더로 하루를 스크럽해 모두에게 맞는 시간대를 찾을 수 있습니다. 각 행에는 UTC 오프셋, 그 도시가 현재 서머타임 중인지, 로컬 타임존에서 본 날짜(3월 5일 오전 9시의 서울 슬롯이 샌프란시스코에서는 "3월 4일 오후 7시"로 표시됨 — 같은 순간, 다른 달력 날짜)도 표시됩니다.
여러 시간대에 걸친 회의 조율, UTC 타임스탬프를 내보내는 서버 로그를 현지 시각으로 해석하고 싶을 때, 여러 시간대에 걸친 항공편이 있는 여행 계획 같은 상황에 사용하세요. 서머타임 전환은 브라우저가 IANA tz database를 통해 처리합니다. `America/Los_Angeles`를 고르면 `PST`와 `PDT` 사이를 자동으로 전환합니다. 모두 로컬에서 동작하며 도시 목록은 업로드되지 않고 시계도 서버에서 가져오지 않습니다.
cities: Seoul, Tokyo, San Francisco, New York, London slider: Seoul 09:00 (March 5)
Seoul 09:00 Wed Mar 5 Tokyo 09:00 Wed Mar 5 San Francisco 17:00 Tue Mar 4 (PST) New York 20:00 Tue Mar 4 (EST) London 01:00 Wed Mar 5 (UTC)
날짜가 바뀐 점에 주목하세요. 서울 수요일 오전 9시는 샌프란시스코에서는 화요일 저녁, 런던에서는 수요일 새벽 1시입니다. 글로벌 회의에서 "모두에게 그럭저럭 괜찮은" 스위트 스폿은 보통 서울 오후(미국 동부의 저녁, 미국 서부의 오후)입니다. 타임 슬라이더로 시험해 보세요.
cities: Tokyo, New York slider: New York 02:30 (March 8)
Tokyo 16:30 Sun Mar 8 New York invalid (DST spring-forward 02:00 → 03:00)
3월 둘째 일요일에 미국 동부 시간은 02:00에서 03:00으로 바로 점프합니다 — 그날의 02:30은 존재하지 않습니다. 본 컨버터는 이를 감지해 "invalid"로 표시하고 02:30 EST나 02:30 EDT를 조용히 고르지 않습니다. 역현상은 11월 첫째 일요일에 일어납니다. 같은 날 01:30이 두 번(첫 번째 EDT, 두 번째 EST) 나타나며, 이를 모호함으로 표시하는 도구도 있고 첫 발생을 고르는 도구도 있습니다.
cities: London (Europe/London), Lisbon (Europe/Lisbon) date: November 2
London UTC+00:00 (GMT, just exited BST) Lisbon UTC+00:00 (WET, just exited WEST)
두 도시가 *오늘*은 같은 오프셋이라도 서머타임 규칙이 달라 연중 다른 시기에는 차이가 날 수 있습니다. 런던은 10월 마지막 일요일에 BST(UTC+1)에서 GMT(UTC+0)로 전환합니다. 리스본도 같은 날에 전환하지만 명칭이 다릅니다(WEST → WET). 11월 2일에는 둘 다 UTC+0이지만 여름에는 런던과 리스본 모두 +1입니다. 전환 시점은 같아도 라벨이 다릅니다. 약어가 아닌 IANA 이름(`Europe/London`·`Europe/Lisbon`)으로 식별하세요.
IANA 이름은 *규칙을 가진 존*을 식별하고 약어는 *현재 오프셋*만 식별합니다. `KST`는 모호하지 않지만(한국은 1988년 이후 서머타임 없음) `CST`는 중국(UTC+8, DST 없음)·미국 중부(UTC−6·−5, DST 있음)·쿠바(UTC−5·−4, DST 있음) 중 어느 것이든 될 수 있습니다. `BST`는 유럽에서는 영국 서머타임이지만 아시아에서는 방글라데시 표준시입니다. `America/New_York` 같은 IANA 이름은 서머타임 전체 스케줄과 역사적 변경을 보유하므로 같은 문자열이 오늘도, 1980년도, 미래의 DST 정책 변경 이후에도 정확하게 동작합니다. 존은 항상 IANA 이름으로 저장·전달하고, 약어는 표시 시점에만 렌더링하세요.
나라마다 다르며 종종 바뀝니다. **미국·캐나다**: 3월 둘째 일요일(전진)과 11월 첫째 일요일(후진). 전환은 현지 02:00. **EU·영국**: 3월 마지막 일요일과 10월 마지막 일요일. 전환은 전체 회원국에서 01:00 UTC. **호주**: 10월 첫째 일요일과 4월 첫째 일요일(남부 주만 시행). **아시아·아프리카·남미 대부분**: 서머타임 없음. 한국은 1988년, 일본은 1952년에 폐지했고, 중국은 모든 곳을 UTC+8로 통일합니다. IANA tz database는 약 1970년 이후의 모든 규칙 변경을 추적하고, 그 이전 날짜에는 역사적 추정치를 제공합니다.
둘 다 옳고, 같은 순간이지만 달력 일이 다릅니다. `00:00 3월 5일`과 `24:00 3월 4일`은 같은 시각입니다. ISO 8601은 사람용 표시에는 `00:00`을 선호하지만 계약서에서 하루의 끝을 나타내는 경계에는 `24:00`을 허용합니다("이 제안은 3월 4일 24:00에 만료"라고 쓰면 자정이 3월 5일부터 시작하는지의 모호함 없이 마감이 명확해집니다). 정밀도가 중요한 자리에서는 `12:00 AM`·`12:00 PM` 표기를 피하세요. 다수의 사람이 자정과 정오의 AM·PM 배치를 잘못 읽습니다. 24시간제를 사용하거나 명시적으로 "정오"·"자정"이라고 쓰세요.
현대 브라우저(Chrome·Edge·Safari 2023 이후)는 최신 IANA tz database를 내장하고 브라우저 릴리스마다(약 6주마다) 갱신합니다. 릴리스 주기 이상 사전에 발표된 DST 규칙 변경은 정확히 동작하지만, 긴급 변경(이집트가 몇 주 전 통보로 여러 차례 DST를 취소)은 1~2 릴리스 주기 늦을 수 있습니다. 서버 측에서 규칙 변경을 더 빠르게 반영하고 싶다면 npm이나 pip에서 업데이트를 가져오는 런타임 tz 라이브러리를 쓰세요(`tzdata` 패키지는 IANA 릴리스 후 며칠 안에 업데이트를 게시합니다).
쌍으로 저장하세요. 로컬 벽시계 시각(`2026-06-15 09:00`)과 IANA 존(`Asia/Seoul`)입니다. 쓰는 시점에 UTC로 변환 *하지 마세요*. 한국이 미래에 서머타임 규칙을 변경한다면(1988년 이후 변경은 없지만 정부가 재검토할 가능성은 있음) 저장된 UTC 값이 잘못될 수 있습니다. 로컬 + 존 조합을 UTC로 변환하는 것은 렌더링 시점에만 *현재* tz 데이터베이스에 대해 수행하세요. PostgreSQL은 `timestamp`와 존용 별도 `text` 컬럼을 함께 두거나 `timestamptz`와 존 컬럼을 함께 둡니다. 반복 이벤트에도 같은 조언이 적용됩니다 — UTC가 아닌 회의의 홈존에서 `RRULE:FREQ=WEEKLY;BYHOUR=9`을 저장하세요.
일부 나라는 30분이나 15분 단위 오프셋을 사용하며 이는 1972년 이전 표준화 이전의 역사적 유물입니다. **인도**는 UTC+05:30(전국 1 존, 동서 경도 차이를 중간으로 나눔). **이란**은 UTC+03:30. **아프가니스탄**은 UTC+04:30. **네팔**은 UTC+05:45(현재 상용되는 유일한 15분 단위 존, 인도에서 15분 어긋난 설정). **채텀 제도**(뉴질랜드)는 UTC+12:45·13:45. IANA tz database는 이 모두를 정확히 다룹니다. IANA 이름으로 식별하세요(`Asia/Kolkata`·`Asia/Tehran`·`Asia/Kathmandu`·`Pacific/Chatham`).
타임존이란 UTC로부터의 벽시계 오프셋과, 필요하다면 1시간의 서머타임 조정을 적용하는 규칙 집합을 공유하는 지역입니다. **IANA tz database**(1986년에 시작한 Arthur David Olson의 이름을 따 Olson database라고도 불림)는 이 규칙들의 정본입니다. 모든 현대 OS와 런타임이 어떤 형태로든 이를 포함합니다 — Linux의 `/usr/share/zoneinfo`, macOS의 `/var/db/timezone`, Windows의 ICU 번들, Node.js의 `Intl.DateTimeFormat`. 데이터베이스는 존을 정치적 경계가 아닌 `Continent/City`(예: `Asia/Seoul`·`America/New_York`·`Europe/Berlin`)로 식별합니다. 한 국가 안에서도 규칙이 갈릴 수 있어서입니다.
**순간과 로컬 시각의 분리**가 핵심 추상입니다. `1741132800` 같은 Unix 타임스탬프는 절대 순간이고 지구 어디서나 같은 때입니다. 그 순간을 벽시계 시각으로 표시하는 방식은 묻는 존에 의존합니다 — `2025-03-05 09:00 KST`와 `2025-03-04 16:00 PST`는 같은 순간입니다. 이 구분을 혼동하는 것이 대다수 캘린더 버그의 원인입니다. 원칙은 과거 이벤트는 UTC로 순간을 저장하고, 미래 이벤트는 `(local_time, zone)`으로 저장하는 것입니다. 미래 이벤트에서는 개최 전에 존 규칙이 바뀔 수 있기 때문입니다.
인접한 3가지 개념이 있습니다. **UTC**(협정 세계시)는 글로벌 기준이며 오프셋은 이에 대해 표현됩니다. **윤초**는 UTC에 가끔 더해지는 1초 조정으로, 마지막 적용은 2016년 12월입니다. Unix 시각은 의도적으로 이를 무시하지만 TAI나 GPS 시각은 세므로 2026년 기준 오프셋이 37초 어긋나 있습니다. 윤초를 폐지하는(2035년 이후) 국제 회의가 진행 중입니다. **서머타임 정책**은 정말로 혼란스럽습니다 — 러시아는 2011년 폐지, EU는 2019년부터 "곧 폐지한다"는 상태가 이어지고, 브라질은 2019년 폐지, 미국 다수 주에서 법안이 심의 중입니다. 미래 DST에 대한 모든 가정을 취약하다고 보고, tz 데이터베이스를 유일한 신뢰 정보원으로 의지하며 정기적으로 갱신하세요.
서력과 일본 연호(明治·大正·昭和·平成·令和)를 양방향으로 변환합니다. 연도 중간 개원일(헤이세이 元年 1989-01-08, 레이와 元年 2019-05-01 등)도 정확하게 처리합니다.
클래식 25 / 5 / 15분 뽀모도로 타이머입니다. 브라우저 알림을 지원하고 localStorage로 완료 세션 수를 기록하며, 가입이나 추적은 없습니다.
서력 기준으로 12지(쥐·소·호랑이·토끼…)와 60갑자를 표시합니다. 한·중·일 정식 명칭도 함께 표기합니다.
Unix 타임스탬프와 ISO 8601 날짜를 양방향으로 변환합니다. 현지/UTC/상대 표현을 동시에 표시하고 입력에 즉시 반영합니다.
