내가 놓친 가장 비싼 회의는 정확하게 예정되어 있었다. 런던의 누군가가 넣어 & quot;내 시간 오후 3 시,오전 10 시 yours" 달력에서 뉴욕에서 나에게 초대,이는 사실이었다 2 월에 작성. 전화는 12 월. 미국은 이전 일요일에 앞으로 시계를 이동했다; 영국은하지 않았다,그리고 또 다른 삼주 동안하지 않을 것. 런던과 뉴욕 사이의 간격,일반적으로 다섯 시간은 그 주에 네이었다 - 그래서 런던에서 오후 3 시,나에 대한 오전 10 시,한 시간 일찍 빈 방에 합류,포기, 그리고 전화를 완전히 놓쳤다.
봄의 3 주 창구 - 그리고 가을의 1 주 창구 - 는 엣지 케이스가 아닙니다. 매년마다 일어나는 일이며,산술에 완벽하게 유능한 사람들을 붙잡습니다. 왜냐하면 산술이 문제가 아니기 때문입니다. 문제는 "London 이 New York" 보다 5 시간 빠르다는 것입니다; 두 도시에 대한 사실이 아닙니다. 두 도시에 대한 사실입니다 특정 날짜에그리고 날짜를 붙이지 않고 적는 순간 버그를 만든 것이다.
시간대는 오프셋이 아닙니다. 순간적으로 먹이를 주면 오프셋을 생성하는 일련의 규칙입니다. 그 규칙은 변경됩니다: 국가는 일광 절약을 채택하거나,그것을 포기하거나,표준 오프셋을 이동하거나,3 주와 함께 영구적 인 변경을 발표합니다' notice. This is why the 시간대 변환기 에 Toolz.dev 오프셋은 어디에도 저장하지 마세요. 라고 묻습니다 이아나 시간대 데이터베이스 - 이미 브라우저 내부에 있는 데이터베이스 - 변환하는 정확한 순간에 대한 오프셋이 무엇인지, 그리고 매 순간 다시 묻습니다.
TL;DR: 두 구역 사이의 간격은 날짜에 따라 달라지는데,이는 일광 절약 전환이 국가 간에 정렬되지 않기 때문입니다. The 시간대 변환기 입력한 특정 순간에 대한 IANA 데이터베이스를 통해 모든 오프셋을 해결하고,UTC 오프셋과 부호 있는 차이를 모두 표시하고,30 분 및 15 분 영역을 처리하고,회의 플래너 스트립의 여러 도시에서 동일한 순간을 배치하는 브라우저에서 완전히 실행됩니다.
주요 특징
오프셋은 즉시 해결되며 하드코딩되지 않습니다
이 도구의 모든 오프셋은 인스턴트를 대상 영역으로 포맷하고 벽시계를 다시 읽어 계산됩니다. 그 단일 디자인 결정은 일광 절약,역사적 규칙 변경 및 정부 법령에 따라 오프셋을 조정하는 국가를 모두 동일한 코드 경로로 유지하는 오프셋 테이블이 없으며 오래 갈 테이블이 없습니다. 1 월 회의와 7 월 베를린과 시카고 간의 동일한 회의를 변환하면 도구가 두 번 모두 7 시간의 간격을 올바르게 제공합니다 - 그러나 3 월 말에 하나를 변환하면 올바르게 6 개를 제공합니다.
50개 이상의 선별된 IANA 구역
피커는 사람들이 실제로 스케줄링한 도시들을 지역별로 그룹화하고,국가로 라벨을 붙이고,전체 IANA 식별자와 함께 보여줍니다. 그 마지막 부분은 보이는 것보다 더 중요합니다: Asia/Kolkata cron 표현식인 Postgres에 붙여넣는 문자열입니다 AT TIME ZONE 절 또는 파이썬 ZoneInfo 생성자. 읽기 "콜카타,인도" 및 복사 Asia/Kolkata 는 두 가지 다른 작업이며 도구는 두 가지 작업을 모두 수행합니다.
회의 플래너 스트립
변환 아래에는 추가하는 각 영역에 인스턴트 주변의 창에 걸쳐 있는 시간 셀이 한 줄씩 표시됩니다. 근무 시간 (09:00 ~ 17:59 로컬) 은 음영 처리되고,초기 및 늦은 시간은 별도로 표시되며,다른 달력일에 해당하는 셀은 a 를 전달합니다 +1d 또는 -1d 배지. 샌프란시스코, 런던, 시드니에서 동시에 문명화된 한 시간을 찾는 것은 어려운 문제입니다. 스트립은 산술이 아닌 시각적인 시간이 됩니다.
30분 및 15분 구역은 정상으로 간주됩니다
인도는 UTC+05:30 입니다. 네팔은 UTC+05:45 입니다. 애들레이드는 겨울에 UTC+09:30 이고 여름에 UTC+10:30 입니다. 채텀 제도는 UTC+12:45 입니다. 대략 5 분의 1 의 world's 인구는 정수가 아닌 오프셋에 살고 있으며,그렇지 않다고 가정하는 도구는 수억 명의 사람들에게 잘못되었습니다. 여기의 오프셋은 몇 분 안에 저장되고 표시됩니다.
입력한 날짜에 표시된 약어입니다
변환의 각 면에는 해당 순간에 유효한 영역 약어 - EST 또는 EDT,GMT 또는 BST,AEST 또는 AEDT 가 표시됩니다. 이는 전환의 어느 면에 착륙했는지 확인하는 가장 빠른 방법입니다. 3 월 날짜를 입력하고 도구에 EDT 라고 표시된 경우 시계가 이미 변경되지 않았습니다. EST 라고 표시된 경우.
완전한 클라이언트 측
모든 계산은 브라우저의 JavaScript에서 실행됩니다 Intl API 와 엔진과 함께 제공되는 시간대 데이터베이스. 입력한 내용이 업로드되지 않고,기록된 내용이 없으며,페이지가 로드되면 변환기는 네트워크 연결이 전혀 없는 상태에서 계속 작동합니다. 이는 또한 기다릴 왕복 여행이 없기 때문에 필드를 변경하는 순간 결과가 업데이트된다는 의미이기도 합니다.
시간대 변환기 사용 방법
1 단계: 소스 영역, 날짜 및 시간을 설정합니다
당신이 변환하는 도시를 선택합니다 부터그리고,거기에 시계가 읽는 그대로 날짜와 시간을 입력합니다. 시간 필드는 24 시간 값을 가지므로 오후 3 시입니다 15:00. 가상의 순간이 아닌 현재의 순간을 원한다면 를 누르십시오 지금- 소스 영역에서 볼 수 있는 현재 날짜와 시간을 로드합니다. 이는 반드시 자신의 벽에 있는 날짜와 동일한 날짜는 아닙니다.
2 단계: 대상 영역을 선택합니다
답을 원하는 도시를 선택하십시오. 변환된 날짜,시간, 12 시간 판독값이 해당 특정 날짜에 적용되는 UTC 오프셋 및 약어와 함께 즉시 나타납니다. 주의할 점은 날짜 변경할 수 있습니다: 뉴욕의 월요일 21:00 은 다카의 화요일 07:00 이며, 도구는 조용히 작업을 위해 당신을 떠나지 않고 새로운 날짜를 보여줍니다.
3단계: 오프셋과 간격을 읽습니다
각 측면 아래에서 오프셋을 얻을 수 있습니다 UTC±HH:MM 양식과 영역 약어. 그들 사이에,도구는 단어 - "Dhaka 는 New York" 보다 10 시간 앞서; - 기억 평균이 아닌 해당 날짜에 대한 올바른 값으로 관계를 명시합니다. 방향을 반대로하려면 스왑 버튼을 사용하여; 그것은 동일하게 유지합니다 인스턴트 그리고 어느 쪽으로 들어가고 있는지 뒤집어 놓는데, 이는 거의 항상 원하는 것입니다.
4 단계: 회의 스트립을 구축
모든 참가자's 영역을 플래너에 추가합니다. 각 행은 해당 영역에서 동일한 순간과 그 주변의 시간을 표시하며 작업 시간은 음영 처리됩니다. 소스 시간을 더 일찍 또는 나중에 슬라이드하고 음영이 움직이는 것을 지켜보십시오. 음영 처리된 셀이 모든 행에 정렬되면 슬롯을 찾은 것입니다.
5 단계: 결과 복사
변환된 시간만 복사하거나 전체 표현식을 복사하세요 Sun, Mar 12, 2026 09:00 EDT (America/New_York) = Sun, Mar 12, 2026 13:00 GMT (Europe/London)- 그리고 달력 초대장에 붙여 넣습니다. 양쪽을 약어로 쓰는 것은 내 런던 실수를 반복하지 않는 가장 효과적인 습관입니다.
시간대 변환이 실제로 작동하는 방법
순진한 정신 모델은 각 영역에 숫자가 붙어 있고 변환은 뺄셈이라는 것입니다. 그 모델은 대부분의 경우 정답을 생성하는 방식으로 잘못되었으며 이는 최악의 실패 모드입니다.
올바른 모델은 세 개의 레이어를 가지고 있습니다.
레이어 1: 순간. 모든 것의 밑에는 보편적인 타임라인의 단일 지점 - 신기원 타임스탬프,1970-01-01T00:00:00Z 이후 초의 카운트. 인스턴트는 모호하지 않습니다. 지구상의 모든 사람들은 시계가 말하는 것이 무엇이든 동시에 같은 순간을 경험합니다.
레이어 2: 오프셋. 오프셋은 로컬 벽시계 시간을 얻기 위해 UTC에 추가할 부호 있는 분 수입니다. UTC-04:00 는 오프셋입니다. a 입니다 결과, 장소의 재산이 아닙니다.
레이어 3: 영역. 영역은 명명된 규칙 집합입니다 - America/New_York- 이는 순간을 오프셋으로 매핑합니다. 이것은 사람들이 레이어 2로 축소하는 레이어이며, 그 붕괴는 지금까지 작성된 거의 모든 시간대 버그의 소스입니다.
따라서 변환은 그렇지 않습니다 localB = localA + delta. 그것은:
instant = resolve(wallClockA, zoneA) // rules of A, applied to that reading
wallClockB = render(instant, zoneB) // rules of B, applied to that instant
두 개의 규칙 조회,중간에 한 순간. 도구는 정확히이 작업을 수행합니다. 한 순간의 영역의 오프셋을 해결하기 위해 해당 영역에 인스턴트를 포맷하고 연도,월, 일,시, 분 및 초를 다시 읽고 해당 필드를 UTC 인 것처럼 처리하고 실제 인스턴트를 뺍니다. 차이점은 분 단위로 IANA 데이터베이스의 engine's 복사본에서 바로 오프셋입니다.
다른 방향으로 - 벽시계 판독에서 순간으로 - 가면 닭과 달걀 문제가 있습니다. 왜냐하면 순간을 찾기 위해 오프셋이 필요하고 오프셋을 찾기 위해 순간이 필요하기 때문입니다. 도구는 순진한 오프셋을 사용하여 한 번 추측하고 추측이 전환의 반대편에 떨어 졌는지 확인하고 그랬다면 수정합니다. 두 번의 조회는 항상 종료되며 DST 경계를 넘어 수정됩니다.
IANA 시간대 데이터베이스
모든 것이 의존하는 데이터베이스는 IANA 에 의해 유지 관리되며 종종 여전히 "Olson database" 1980 년대에 시작한 Arthur David Olson 이후 모든 운영 체제,모든 브라우저,모든 JVM 및 모든 Python 설치 내부에 배송되며 정부가 계속 마음을 바꾸기 때문에 1 년에 여러 번 업데이트됩니다.
식별자는 형식을 취합니다 Area/Location: America/New_York, Europe/London, Asia/Kolkata, Australia/Sydney. 위치는 대표 도시이지 정치적 주장이 아니다 - America/New_York 미국 동부 지역 전체를 포괄하며 인디애나는 일광 절약 시간제를 준수할지 여부에 대해 수십 년 동안 동의하지 않았기 때문에 자체 식별자가 12개 필요한 것으로 유명합니다.
데이터베이스가 저장하는 것은 영역당 단일 오프셋이 아니라 전체 규칙 기록입니다. It knows that Ukraine's Europe/Kyiv ~였다 Europe/Kiev 2022년 철자가 업데이트될 때까지. 이집트가 2014년에 일광 절약 시간제를 포기한 후 2023년에 다시 도입했다는 것을 알고 있습니다. 사모아가 국제 날짜 변경선을 뛰어넘었을 때 2011년 12월 30일을 완전히 건너뛰었다는 것을 알고 있습니다. 그 역사가 동일한 도시 쌍에 대해 2015년 날짜와 2025년 날짜를 변환하는 것이 합법적으로 다른 답변을 생성할 수 있는 이유이며, 하드코드 오프셋 도구가 과거에 대해 거짓말을 하는 도구인 이유입니다.
소프트웨어를 작성하는 모든 사람의 실제 결과: 인스턴트를 UTC 에 저장하고,user's 영역을 IANA 식별자로 저장하고,디스플레이 레이어에서만 변환합니다. 오프셋을 저장하지 마십시오. 오프셋은 규칙의 렌더링이며,규칙이 변경됩니다. epoch 값으로 직접 작업하는 경우 타임스탬프 변환기 날짜로 다시 읽어주는 동반 도구입니다.
UTC 오프셋, 약어 및 영역 이름: 사용할 항목입니다
이 세 가지는 끊임없이 혼동되며, 서로 바꿔 쓸 수 없습니다.
| 양식 | 예 | 안정적인? | 독특한? | 위해 사용하십시오 |
|---|---|---|---|---|
| IANA 존 이름 | America/New_York |
네, DST 건너편입니다 | 예 | 스토리지, 코드, 구성, API |
| UTC 오프셋 | UTC-04:00 |
아니요, DST로 변경됩니다 | 아니요 | 즉시 부착된 디스플레이, 와이어 형식 |
| 약어 | EDT |
아니요, DST로 변경됩니다 | 아니요 | 인간 대면 디스플레이만 |
살인자는 그 마지막 열입니다. 약어는 유일하지 않습니다. CST 미국 중부 표준시, 중국 표준시, 쿠바 표준시를 의미합니다. 세 가지 다른 오프셋, 하나의 문자열입니다. IST 인도 표준시, 아일랜드 표준시, 이스라엘 표준시를 의미합니다. BST 는 영국 서머타임,그리고 또한 부건빌 표준시를 의미한다. 만약 시스템이 받는다면 CST 추측을 통해 누군가는 잘못된 추측을 하게 될 것입니다.
오프셋 형식은 모호하지 않지만 안정적이지는 않습니다: UTC+01:00 instant's 렌더링을 올바르게 식별하지만 영역이 아니며 이를 사용하여 계산할 수 없습니다 다음 Tuesday's 렌더링,왜냐하면 다음 주 화요일은 전환의 반대편에 떨어질 수 있기 때문입니다.
IANA 이름만이 규칙을 담고 있습니다. 여러분이 지속해야 할 세 가지 중 유일한 것입니다.
두 도시 간 격차가 계속 움직이는 이유
일광 절약 시간이 그 이유이며, 이것이 그토록 힘든 이유는 국가들이 전환을 동기화하지 않기 때문입니다.
- 미국 3 월 둘째 주 일요일에는 앞으로 튀어 오르고 11 월 첫째 주 일요일에는 다시 떨어집니다.
- 유럽 연합은 3 월 마지막 일요일에 앞으로 튀어 나와 10 월 마지막 일요일에 다시 떨어집니다.
- 호주남반구에 있는 것은 그 반대입니다: 10월에 전진하고 4월에 다시 돌아옵니다. 퀸즈랜드, 서호주, 노던 테리토리에서는 전혀 그렇게 하지 않습니다.
- 인도, 중국, 일본, 아프리카 대부분, 아시아 대부분 어느 시점에서도 관찰하지 마십시오.
그것들을 정렬하면 일반적인 간격이 단순히 잘못된 겹치는 창이 나타납니다:
| 기간 | 뉴욕 시계 | 런던 시계 | 갭 |
|---|---|---|---|
| 겨울의 대부분 | EST(UTC−05:00) | GMT(UTC+00:00) | 5 시간 |
| 3 월 둘째주 일요일 → 3 월 마지막 일요일 | EDT(UTC−04:00) | GMT(UTC+00:00) | 4 시간 |
| 여름의 대부분 | EDT(UTC−04:00) | BST(UTC+01:00) | 5 시간 |
| 10 월 마지막 일요일 → 11 월 첫째 일요일 | EDT(UTC−04:00) | GMT(UTC+00:00) | 4 시간 |
일년에 두 개의 창 - 봄에는 대략 3 주,가을에는 1 주 - 모든 "we're 항상 다섯 시간 떨어져" 달력에서 가정은 한 시간 떨어져 있습니다. 그리고 그것은 단지 한 쌍의 도시입니다. 전환이 반대 방향으로 진행되는 시드니를 추가하고 일년에 걸쳐 뚜렷한 간격 값의 수가 빠르게 증가합니다.
전환 자체가 이름을 붙일 가치가 있는 두 가지 위험을 더 만듭니다. 시계가 앞으로 튀어 나올 때 현지 시간으로 한 시간 존재하지 않습니다- 02:30 뉴욕의 전환의 밤은 진짜 독서가 아닙니다 시계가 뒤로 떨어지면 현지 시간으로 한 시간 두 번 발생합니다그리고 맨 벽시계 판독은 정말 모호합니다. 변환기는 존재하지 않는 시간을 전환 직후의 순간으로, 모호한 시간을 첫 번째 발생으로 해결합니다. 이는 대부분의 달력 소프트웨어가 따르는 관례입니다. 이는 방어 가능한 유일한 선택은 아니지만 가장 적은 놀라움을 생성하는 선택입니다.
일반적인 사용 사례
분산된 팀 전체에서 회의 일정을 계획합니다. 명백한 것, 그리고 플래너 스트립이 존재하는 것. 세 개 이상의 영역은 암산술이 안정적으로 실패하는 곳입니다. 특히 그 중 하나가 30분 오프셋 상태이거나 남반구에 있을 때 더욱 그렇습니다.
달력 초대 및 공지 사항을 작성합니다. 항상 시간을 영역으로 명시하고,항상 적어도 두 개의 렌더링을 제공하고,"my time"보다 IANA 이름 또는 완전한 자격을 갖춘 약어를 선호합니다. "14:00 UTC (10:00 EDT / 19:30 IST)"는 모호하지 않습니다. "2pm"는 동전 던지기입니다.
로그의 타임스탬프 디버깅. 서버가 UTC 에 로그인하고,고객이 현지 시간에 사건을 보고하며,요청을 찾기 전에 두 가지를 조정해야 합니다. customer's 보고서를 UTC 로 변환한 다음 검색합니다. 로그가 ISO 문자열이 아닌 epoch 값인 경우,이를 통해 실행합니다 타임스탬프 변환기 첫번째.
크론 작업 및 배경 작업 일정을 계획합니다. UTC 로 설정된 서버의 cron 표현식은 user's 일광 절약 변경으로 이동하지 않으며,이는 일반적으로 원하는 것입니다 - 그리고 때때로 정확하게 당신이하지 않는 것은 작업이 DST 관찰 국가의 고객을 위해 09:00 로컬에서 실행되도록되어있는 경우 일정을 커밋하기 전에 두 판독 값을 모두 해결합니다; the 크론 파서 당신의 표현이 실제로 무엇을 의미하는지 알려줄 것입니다.
가족과의 여행 및 통화 계획. 출발 및 도착 시간은 항상 각 공항에서 현지 시간으로 주어지며,이는 flight's 명백한 지속 시간이 같은 구역으로 양쪽 끝을 변환 할 때까지 말도 안되는 것입니다. "departs"가 도착하기 전에 도착하는 14 시간 비행은 단지 날짜 선 횡단 일뿐입니다.
발사, 배치 및 금수 조치를 조정합니다. 여러 시장에서 하드 컷오프가 있는 모든 것은 UTC 로 표현되는 단일 인스턴트가 필요하며 각 지역에 대한 로컬 렌더링이 첨부되어 있습니다. 시계 판독이 아닌 해당 인스턴트까지 남은 일수를 계산하는 경우,the 날짜 차이 계산기 는 워크플로의 나머지 절반이다.
자주 묻는 질문
EST를 IST로 어떻게 변환합니까?
선택 America/New_York 근원으로 및 Asia/Kolkata 목표로. 인도는 동부 표준시 동안 뉴욕보다 10시간 30분 앞서 있고 동부 일광 절약 시간 동안에는 9시간 30분 앞서 있습니다. 왜냐하면 인도는 일광 절약 시간을 준수하지 않고 미국도 준수하기 때문입니다. 그 변화하는 격차가 바로 단일 숫자를 기억하기보다는 날짜에 맞춰 전환해야 하는 이유입니다.
EST와 EDT의 차이점은 무엇입니까?
EST (동부 표준시) 는 UTC−05:00 이며 겨울에 적용된다. EDT (동부 일광 절약 시간) 는 UTC−04:00 이며 3 월 둘째 일요일부터 11 월 첫째 일요일까지 적용된다. "Eastern Time" 또는 ET 는 현재 시행 중인 어느 것을 의미하는 포괄적 용어이다. 문서와 코드에서는 IANA 식별자를 선호한다 America/New_York1년 내내 분명합니다.
이 변환기는 일광 절약 시간제를 처리합니까?
예,그리고 오늘이 아니라 입력한 날짜에 대해 그렇게 합니다. 모든 zone's 오프셋은 변환하는 특정 순간에 IANA 시간대 데이터베이스를 통해 해결되므로 3 월 1 일 회의와 3 월 15 일 뉴욕과 런던 간의 동일한 회의에서 각각 5 시간 간격과 4 시간 간격이 올바르게 표시됩니다 - 미국은 유럽보다 3 주 전에 시계를 앞으로 움직입니다.
IANA 시간대 식별자란 무엇입니까?
와 같은 이름이다 America/New_York, Europe/London, 또는 Asia/Kolkata IANA 시간대 데이터베이스에서 가져온,현재 오프셋뿐만 아니라 모든 역사적 규칙 변경을 기록하는 참조 데이터 세트. 식별자는 영역/위치 쌍이며,그들은 소프트웨어에서 영역을 명명하는 유일한 안전한 방법입니다. 왜냐하면 CST 와 같은 약어는 모호하기 때문입니다 - US Central,China Standard,Cuba Standard 모두 그것을 주장합니다.
일부 시간대에 30분 또는 45분 오프셋이 있는 이유는 무엇입니까?
구역은 기하학적이지 않고 정치적이기 때문입니다. 인도는 단일 시계로 넓은 나라를 운영하기 위해 UTC+05:30을 선택했습니다. 네팔은 인도보다 15분 앞서 앉기 위해 UTC+05:45를 선택했습니다. 애들레이드는 UTC+09:30이고 채텀 제도는 UTC+12:45입니다. 오프셋이 전체 시간이라고 가정하는 모든 코드는 결국 세계의 약 5분의 1's 인구에 대해 잘못될 것입니다.
UTC는 무엇이며 GMT와 어떻게 다른가요?
UTC (협정 세계시) 는 모든 구역이 오프셋으로 정의되는 원자 시계 표준입니다. GMT (그리니치 표준시) 는 겨울에 UTC+00:00 과 같은 시간대입니다 - 영국은 여름에 BST (UTC+01:00) 로 이동하므로 "GMT" 및 "London time" 일년 내내 같은 것이 아닙니다. UTC 에 인스턴트를 저장하고 비교하십시오; 디스플레이 전용 구역으로 변환하십시오.
세계에 몇 개의 시간대가 있습니까?
이론상으로는 24 개의 1 시간 대역이 있지만,30 분 및 15 분 구역이 계산되면 약 38 개의 별개의 UTC 오프셋이 실제로 사용되며,UTC−12:00 에서 UTC+14:00 에 걸쳐 있습니다. 그 26 시간 스프레드는 지구상의 두 장소가 같은 순간에 다른 달력 날짜에 있을 수 있는 이유입니다. IANA 데이터베이스 자체는 현재 규칙뿐만 아니라 역사적 규칙을 추적하기 때문에 수백 개의 명명된 영역을 정의합니다.
일광 절약 시간제에 빠진 시간은 어떻게 되나요?
시계가 앞으로 튀어 나오면 한 시간의 현지 시간은 결코 존재하지 않으므로 뉴욕의 전환 밤 02:30 은 실제 독서가 아닙니다. 변환기는 그러한 입력을 전환 직후의 순간으로 해결합니다. 조용히 잘못된 대답을 반환하는 대신 동일한 벽시계가 두 번 발생하는 가을의 시간이 겹치면 첫 번째 발생으로 해결됩니다 - 대부분의 달력 소프트웨어가 따르는 규칙.
