시간대 변환기

시간대는 어떻게 작동합니까?: UTC와 오프셋

UTC (협정 세계시)는 전 세계의 시간 표준 — 모든 다른 시간대는 이로부터 파생됩니다. 시간대는 UTC 오프셋으로 표시됩니다: UTC+X는 UTC 앞 X 시간을 의미하며 UTC−X는 UTC 뒤 X 시간을 의미합니다.

두 시간대 사이를 변환하려면:

1. 원본 시간을 UTC로 변환: 원본 UTC 오프셋을 뺍니다.
2. 목표 UTC 오프셋을 더합니다.

예시: 뉴욕 (EST = UTC−5)에서 3:00 PM을 런던 (GMT = UTC+0)으로 변환하세요:
3:00 PM − (−5시간) = 3:00 PM + 5시간 = 8:00 PM UTC = 8:00 PM 런던 시간

예시: 도쿄 (JST = UTC+9)에서 10:00 AM을 뉴욕 (EST = UTC−5)으로 변환하세요:
10:00 AM UTC+9 → UTC: 10:00 AM − 9시간 = 1:00 AM UTC → EST: 1:00 AM − 5시간 = 8:00 PM 전날 뉴욕

주요 시간대 참조 차트

세계 주요 도시의 UTC 오프셋 (표준 시간, 비 DST):

일광 절약 시간 (DST): 시계가 바뀌는 시간

일광 절약 시간은 봄에 시계를 1시간 앞으로, 가을에 1시간 뒤로 옮깁니다 — 여름 달 동안 UTC 오프셋이 바뀝니다.

일광 절약 시간을 관찰하지 않는 국가로는 일본, 중국, 인도, 아프리카 대부분, 중동의 일부가 있습니다. 아리조나 (미국)와 인디애나의 일부도 일광 절약 시간을 관찰하지 않습니다.

실용적 영향: 뉴욕과 런던 사이의 시간 차이는 겨울에는 5시간이지만 봄/가을에는 4시간이지만 두 지역이 서로 다른 일광 절약 시간을 관찰할 때 5시간이 다시 됩니다.

시간대와 글로벌 러닝 이벤트

국제 경주 결과를 추적하거나 가상 이벤트에 등록하는 러너들에게 시간대 인식은 중요합니다:

• 보스턴 마라톤: 10:00 AM ET에 시작합니다. 라이브 방송: 3:00 PM 런던 (BST), 11:00 PM 도쿄, 6:00 AM PST (같은 날)
• 런던 마라톤: 9:00 AM BST (4월 UTC+1)에서 시작합니다. 미국 관람객: 4:00 AM ET, 1:00 AM PT
• 베를린 마라톤: 9:15 AM CEST (9월 UTC+2)에서 시작합니다. 뉴욕: 3:15 AM ET
• 도쿄 마라톤: 3월 9:10 AM JST (UTC+9)에서 시작합니다. 뉴욕: 전날 저녁 8:10 PM ET

국제 참가자와 함께 가상 러닝 챌린지 또는 온라인 경주를 스케줄링할 때 항상 UTC 시간을 사용하여 모호성을 피하십시오.

국제 비즈니스 시간: 겹치는 창

원격 팀과 글로벌 비즈니스는 실시간 협업을 위해 겹치는 작업 시간에 의존합니다. 아래 표는 표준 비즈니스 시간 (9시 - 17시 지역 시간)과 주요 비즈니스 허브 간의 겹침 창을 보여줍니다.

시간대별 스케줄링 팁:

• 미국-유럽 팀의 경우, ET (유럽 시간대) 아침 시간대가 가장 좋은 창입니다.
• 미국-아시아 팀의 경우, PT (아시아 시간대) 아침 시간대 또는 ET (아시아 시간대) 저녁 시간대가 동시 회의에 적합한 유일한 옵션일 수 있습니다. - 동시 회의 대신 비동기 통신 (슬랙, 루움 비디오)을 고려하십시오.
• 동시 회의 시간을 회전시키면 동일한 지역이 항상 불편한 시간대에 겹치지 않도록 하십시오.
• 실시간 회의를 녹음하여 실시간 회의에 참석할 수 없는 팀원에게 제공하십시오.

완전한 UTC 오프셋 참조 표

세계적으로 사용 중인 모든 UTC 오프셋, 대표적인 도시 및 영토:

참고: 국제 일자선 (IDL)은 태평양을 따라 약 180° 경계를 따라 위치하고 있습니다. 서쪽으로 이동하면 하루를 추가하고 동쪽으로 이동하면 하루를 빼냅니다. UTC+14의 키리바시 라인 제도와 UTC-12의 베이커 아일랜드는 물리적으로 가깝지만 26시간 차이 - 지구에서 가능한 최대 시간 차이입니다.

A Brief History of Time Zones

Before standardized time zones, every city kept its own local solar time — noon was defined as when the sun reached its highest point. This worked fine when travel was slow, but the railroad revolution of the 19th century made local solar time chaotic. A train traveling from New York to Chicago would pass through dozens of "time zones," each city minutes apart. Railroad timetables were nearly impossible to coordinate.

Key milestones in time zone history:

• 1847: British railways adopt Greenwich Mean Time (GMT) as "Railway Time," the first standardized time over a large area.
• 1878: Canadian railway engineer Sir Sandford Fleming proposes a worldwide system of 24 standard time zones, each 15° of longitude wide.
• 1883: US and Canadian railroads adopt four continental time zones (Eastern, Central, Mountain, Pacific) on November 18 — "The Day of Two Noons."
• 1884: The International Meridian Conference in Washington, D.C. establishes the Prime Meridian at Greenwich and recommends a universal day starting at midnight GMT.
• 1918: The US Congress passes the Standard Time Act, making time zones federal law and introducing Daylight Saving Time (later repealed, then reintroduced).
• 1972: UTC (Coordinated Universal Time) replaces GMT as the world's time standard, based on atomic clocks rather than astronomical observations.

Today, there are 38 distinct UTC offsets in use (including half-hour and 45-minute offsets), covering 195 countries with varying DST policies. Some countries have changed time zones for political reasons — North Korea created its own "Pyongyang Time" (UTC+8:30) in 2015, then reverted to UTC+9 in 2018 to align with South Korea during diplomatic talks.

Time Zones in Software Development

Time zone handling is one of the most common sources of bugs in software. Critical rules for developers and anyone working with time data:

• Store all timestamps in UTC. Convert to local time only for display. This prevents ambiguity from DST transitions, time zone changes, and cross-region data comparison.
• Use the IANA/Olson time zone database (e.g., "America/New_York" instead of "EST"). Abbreviations like "CST" are ambiguous — it could mean US Central, China Standard, or Cuba Standard Time.
• Never compute time zone offsets manually. Use well-maintained libraries (moment-timezone, date-fns-tz, Python's pytz or zoneinfo, Java's java.time). Time zone rules change frequently — countries alter DST rules, create new zones, or shift offsets with little advance notice.
• Handle DST transitions explicitly. The hour from 2:00–3:00 AM "disappears" in spring (spring forward) and "repeats" in fall (fall back). Scheduling events at 2:30 AM on a DST transition day requires special handling.
• ISO 8601 format: Always include the time zone offset when exchanging timestamps: 2024-03-15T14:30:00-05:00 (New York) or 2024-03-15T19:30:00Z (UTC, indicated by the "Z" suffix).

Major time zone database updates are released 3–10 times per year by the IANA. Keeping your operating system and runtime libraries updated ensures your applications handle the latest time zone rules correctly.

World Clocks: Current Time Difference Quick Reference

When you need to know the time in another city relative to your location, use this difference chart. Find your city in the left column and read across to find the hour difference to the target city:

Note: Differences shown for standard time. DST shifts can change these by ±1 hour seasonally. When both cities observe DST simultaneously, the difference remains the same.

시간대가 여러 개 있는 국가

대형 국가가 여러 시간대에 걸쳐 있습니다. 시간대 수는 대략 동서 방향의 범위와 관련이 있습니다.

중국의 단일 시간대 정책은 베이징 시간에서 서부 신장의 일출이 10:00에 이르기까지 늦을 수 있습니다. - 그리고 일부 지역에서는 2시간의 오프셋을 사용합니다. 인도도 유사한 실질적인 문제를 마주합니다: 동부와 서부 해안 사이의 일출 시간은 거의 2시간 차이가 나지만, 전 국가가 IST (UTC+5:30)를 사용합니다.

실제로 시간대 관리를 위한 도구

우리 변환기 외에도 일상 생활과 업무를 관리하는 데 도움이 되는 여러 접근 방식이 있습니다.

• 구글 캘린더: 이벤트 시간을 로컬 시간대로 자동으로 변환합니다. 이벤트를 생성할 때 "초기 시간대"를 설정하여 두 개의 시간대 동시 표시가 가능합니다. - 미국 동부와 미국/유럽의 팀 간에 적합합니다.
• 월드 타임 버디 (worldtimebuddy.com): 여러 도시의 비즈니스 시간을 동시적으로 표시하는 시간대 겹침 도구입니다.
• 슬랙/팀즈: 팀원 프로필을 마우스 오버하여 로컬 시간을 확인할 수 있습니다. 양자 플랫폼 모두 스케줄링 기능에서 시간대 컨텍스트를 표시합니다.
• 아이폰/안드로이드 월드 클록: 전화 앱의 클록에 도시를 추가하여 여러 시간대를 한 눈에 볼 수 있습니다.
• "태양을 따라" 모델: 일부 글로벌 기업은 태양을 따라 workflow를 사용하여 다른 시간대에 있는 팀 간에 작업을 전달하여 근 24시간의 생산성을 허용합니다. 런던 팀은 9-5, 뉴욕 팀은 5시 런던 = 12시 뉴욕, 뉴욕 팀은 샌프란시스코 팀에게 전달, 샌프란시스코 팀은 시드니 팀에게 전달, 시드니 팀은 런던 팀에게 다시 전달합니다.

제트 래그의 규칙: 시간대 변경에 대한 체조는 대략 1 시간당 1 시간으로 여행하는 동쪽과 1.5 시간당 1.5 시간으로 여행하는 서쪽으로 조정됩니다. 뉴욕에서 런던 (5 시간 동쪽) 여행은 5 일 동안 완전히 조정되며 뉴욕에서 도쿄 (14 시간) 여행은 거의 2 주가 걸립니다. 빛 노출 시간은 조정 속도를 가속화하는 가장 강력한 도구입니다 - 목적지 시간대에 아침에 밝은 빛을 찾으세요.

국제 일자선과 달력의 특이점

국제 일자선 (IDL)은 태평양에 위치한 180° 경선에 위치한 가상의 선입니다. 서쪽으로 이동할 때는 일자를 건너뛰고, 동쪽으로 이동할 때는 일자를 반복합니다. 이로 인해 다음과 같은 특이한 현상이 발생합니다.

• 사모아의 2011년 일자선 점프: 2011년 12월, 사모아는 동쪽의 IDL에서 서쪽으로 이동하여 12월 30일을 건너뛰었습니다. 국가가 목요일 12월 29일부터 토요일 12월 31일로 바로 넘어갔습니다. 이 변화는 호주와 뉴질랜드와의 무역 파트너를 맞추기 위해 이루어졌습니다.
• 키리바시의 시간대 확장: 키리바시는 일자선에 걸쳐 있습니다. 1995년, 국가가 일자선을 동쪽으로 이동하여 전 국가가 같은 달력 일자에 위치하도록 하였습니다. 이로 인해 UTC+14 시간대가 만들어졌습니다. 이는 세계에서 가장 앞서 있는 시간대입니다.
• 디오메디 제도: 디오메디 제도 (러시아, UTC+12)와 리틀 디오메디 (미국, UTC−9)는 베링 해협에서 3.8km 떨어져 있지만, 시간 차이는 21시간이며, 달력 일자도 다릅니다. 이 간격은 "오늘과 어제가 만나는 곳"이라고도 불립니다.

흥미로운 사실: IDL과 UTC+14/UTC−12 offset으로 인해, 지구상에서 26시간이 존재합니다. 어떤 시점에선 3개의 달력 일자가 존재합니다 (IDL의 "어제" 쪽, 대부분의 지역의 현재 일자, UTC+13/+14 지역의 "내일" 일자).

원격 근무에 대한 시간대 예의

원격 근무가 일반화되면서, 시간대 예의는 전문가로서 필수적인 능력입니다. 분산 팀의 핵심 원칙:

• 동시성 기본: 메시지가 수신자의 근무 시간에 읽히는 것을 가정하고, 메시지에 필요한 모든 맥락을 포함하여 읽을 때 질문이 필요하지 않도록 작성하십시오.
• 시간대 명시: "3시"는 모호합니다. 항상 "3시 ET" 또는 "UTC−5 3시"를 명시하십시오. 더 좋다면, 각 참가자에게 자동 변환되는 스케줄링 도구를 사용하십시오.
• 오프아웃 시간 존중: 수신자의 시간 11시에 슬랙 메시지를 보낸다면, 비동기 커뮤니케이션을 사용하는 문화라면 (내일 아침에 읽을 수 있습니다) 괜찮습니다. 전화 또는 즉시 반응을 기대하는 것은 아닙니다.
• 결정 문서화: 시간대 차이로 인해 참석하지 못한 팀원들이 참여한 결정에 대해, 공유 채널에 명확한 요약을 작성하십시오. 누구도 지리적 위치로 인해 불이익을 받지 않도록 하십시오.
• 불편 회전: 팀이 8시간 이상의 시간대 차이를 보유한다면, 일정 시간을 교대로 하여, 항상 7시 또는 10시를 전화하는 사람들을 교체하십시오.

GitLab (전체 원격, 2,000명 이상의 직원, 60개국 이상)과 Automattic (워드프레스 부모, 1,900명 이상의 직원, 90개국 이상)과 같은 회사들은 시간대 관리에 대한 세부적인 매뉴얼을 발간하여, 분산 팀에 유용한 참고 자료로 사용할 수 있습니다.