2026년 11월 1일 뉴욕의 일정 두 개에 모두 01:30이라고 적혀 있습니다. 시계 숫자만 빼면 0분입니다. 하지만 시작이 UTC−04:00의 01:30, 끝이 UTC−05:00의 01:30이라면 실제로는 60분이 지났습니다. 두 번 나타나는 01:30 중 어느 쪽인지 빠져 있던 것입니다.
이 글에서는 사례 일곱 개를 생성해 Python으로 계산하고, 아래 도구가 사용하는 JavaScript 모듈의 결과와 대조했습니다. 누군가의 실제 캘린더나 일정 개선 효과를 조사한 기록은 아닙니다. 캘린더 서비스의 동작 시험도 하지 않았습니다.
시계 표시·UTC 차이의 변화·경과 시간을 나눕니다
시계 표시 차이는 UTC 차이를 빼고 적힌 날짜와 시각만 비교한 값입니다. UTC 차이의 변화는 끝의 UTC 차이에서 시작의 것을 뺀 값입니다. 실제 경과 시간은 첫 번째 값에서 두 번째 값을 뺍니다. 자정을 넘으면 끝 날짜도 필요합니다.
두 번의 01:30에서는 시계 차이가 0분입니다. UTC 차이는 −240분에서 −300분으로 바뀌므로 변화량은 −60분입니다. 따라서 0 − (−60) = 60분입니다. UTC로 바꾼 양 끝은 05:30과 06:30입니다. 프로그램이 시간을 새로 만든 것이 아니라 같은 순간을 표현하는 기준을 맞춘 것입니다.
| 생성한 사례 | 적힌 시작과 끝 | 시계 표시 차이 | 실제 경과 |
|---|---|---|---|
| 뉴욕의 봄 전환 | 3월 8일 01:30 −05:00 → 03:30 −04:00 | 120분 | 60분 |
| 뉴욕의 가을 구간 | 11월 1일 00:30 −04:00 → 02:30 −05:00 | 120분 | 180분 |
| 두 번의 01:30 | 11월 1일 01:30 −04:00 → 01:30 −05:00 | 0분 | 60분 |
| 서울의 자정 | 10월 24일 23:30 +09:00 → 25일 00:30 +09:00 | 60분 | 60분 |
| 서울과 UTC 표기 | 10월 25일 09:00 +09:00 → 00:00 +00:00 | −540분 | 0분 |
| 평소 서울 한 시간 | 10월 25일 09:00 +09:00 → 10:00 +09:00 | 60분 | 60분 |
| 카트만두와 UTC 표기 | 10월 25일 09:00 +05:45 → 03:30 +00:00 | −330분 | 15분 |
표의 날짜는 모두 2026년입니다. 음수인 시계 차이는 다르게 표시한 시계를 비교한 값이며 실제 시간이 거꾸로 흘렀다는 뜻이 아닙니다. UTC 차이를 정수 시간으로만 처리하면 카트만두 사례의 15분도 놓칩니다.
UTC 차이 하나를 바꾸고 양 끝을 확인합니다
아래 도구는 생성한 예시부터 보여 줍니다. 다른 예시를 선택하거나 네 칸을 바꿀 수 있습니다. 계산을 공유할 때는 날짜와 시작·끝의 UTC 차이를 함께 적으세요. 이 도구는 입력한 숫자의 산술만 비교합니다. 도시를 식별하거나 그 지역에 실제로 존재하는 시각인지는 판정하지 않습니다.
시계 표시와 실제 경과를 직접 비교하기
입력은 이 페이지에서만 계산하며 저장·전송하지 않습니다. 지역의 실제 서머타임 규칙을 검증하는 도구가 아닙니다.
두 번의 01:30 예시를 선택한 뒤 끝의 UTC 차이를 −05:00에서 −04:00으로 바꿔 보세요. 양 끝이 같은 순간이 되면서 경과 시간이 60분에서 0분으로 바뀝니다. 다음 예시를 보기 전 원래 예시를 다시 선택하면 됩니다. 실제 약속을 옮긴 것이 아니라 생성 입력 하나만 바꾼 비교입니다.
Python에서 무엇을 빼는지도 확인했습니다
지역을 지정하는 입력은 Python의 ZoneInfo를 사용했습니다. 모호한 시각의 첫 번째와 두 번째 발생을 fold로 구분합니다. zoneinfo 공식 설명에서 전환 전후를 어떻게 구분하는지 확인할 수 있습니다. 프로그램은 두 번 오는 시각에 그 구분을 요구하며 처음 값을 임의로 고르지 않습니다.
같은 tzinfo 객체를 가진 두 datetime을 바로 빼면 시계 표시를 따라간다는 주의점도 확인했습니다. 두 번의 01:30을 바로 빼면 0분입니다. 이는 datetime의 공식 뺄셈 규칙에 설명된 동작이지 Python 시험 실패가 아닙니다. 실제 경과를 묻는 계산에서는 양 끝을 UTC로 바꾼 뒤 빼서 60분을 얻었습니다. JSON에는 두 결과를 모두 남겼습니다.
UTC 차이가 그럴듯해도 지역 시각이 유효한 것은 아닙니다
지역 검증에서는 2026년 3월 8일 뉴욕의 02:30도 입력했습니다. UTC로 바꿨다가 다시 뉴욕으로 돌렸을 때 요청한 지역 시각으로 돌아오지 않아 거절했습니다. 가을에 두 번 오는 시각에서 어느 발생인지 빠진 입력도 따로 거절했습니다. 반면 브라우저 도구는 지역 시간대 데이터베이스를 조회하지 않습니다. 특정 도시에 없는 시각이라도 날짜와 UTC 차이의 숫자가 유효하면 산술 결과가 나올 수 있습니다.
실제 초대장에서는 날짜·지역 시간대·명확한 양 끝을 캘린더 제공자나 주최자에게 확인하세요. 나라 이름만 보고 UTC 차이를 추측하지 마세요. IANA 시간대 데이터는 제도 변경에 따라 바뀝니다. 이번 실행은 설치된 지역 파일의 해시를 기록했으며 모든 기기의 전 세계 규칙이 최신이라는 인증이 아닙니다. 미래 일정은 규칙 변경이 있으면 다시 확인해야 합니다.
개인 일정 없이 같은 계산을 재현할 수 있습니다
Python 소스, 생성 CSV, 전체 결과, 브라우저 모듈을 공개합니다. Python 실행에는 3.9 이상과 이용 가능한 시스템 시간대 자료가 필요합니다. 환경에 그 자료가 없더라도 이 글의 표와 명시한 UTC 차이 계산기는 별도 설치 없이 볼 수 있습니다.
정상 사례 일곱 개는 명시한 예상값과 일치했습니다. 빌더는 실제 브라우저 모듈의 예시 일곱 개도 Python 결과와 비교했습니다. 존재하지 않는 시각, 발생 구분이 없는 모호한 시각, 잘못된 날짜, 잘못된 fold, 빠진 UTC 차이, UTC 기준으로 뒤집힌 양 끝의 여섯 입력은 의도대로 거절했습니다. 이는 예상 오류 감지 성공이며 약속이나 Google 심사가 실패한 기록이 아닙니다. 두 구현을 같은 작성자가 만들었으므로 독립 전문가 검수로 부르지 않습니다.
이 모형은 분 단위이며 윤초·반복 일정 전개·캘린더 가져오기·일정 최적화는 다루지 않습니다. 명확한 두 순간 사이가 얼마인지를 답합니다. 양 끝을 확인한 여러 약속을 합치려면 별도의 겹침·점유 시간 계산으로 이어가세요. 일정별 길이를 더하는 것만으로 동시 약속이 해소되지는 않습니다.