ICS Maker잘못된 시간대

일정이 잘못된 시간에 표시될 때

"초대장 시간이 한 시간 어긋난다"는 문제는 거의 대부분 다음 세 가지 중 하나입니다. 시간대가 없는 시간, 읽는 캘린더가 인식하지 못하는 시간대, 또는 하루 종일 일정이 시간 지정 일정으로 처리되는 경우입니다.

제목, 장소, 날짜와 시간, 시간대, 반복, 참석자, 알림, 메모를 입력한 다음 .ics 파일을 내려받거나 캘린더에서 바로 여세요. 일정을 붙여 넣거나 문서 또는 사진을 첨부해 여러 일정을 한 번에 만들 수도 있습니다.

왜 내 캘린더 일정이 한 시간, 또는 하루 어긋나 있나요?

.ics 파일은 시간을 세 가지 방식으로 표현할 수 있으며, 잘못된 방식을 사용한 것이 거의 항상 원인입니다. 부동 시간(DTSTART:20260815T090000, 시간대 없음)은 어디에서 열든 9시입니다. UTC 시간(끝에 Z가 붙음)은 하나의 절대적인 순간입니다. 명명된 시간대(DTSTART;TZID=Europe/London:...)는 서머타임이 적용되어도 같은 현지 시각을 유지하는 순간입니다. 한 시간 어긋난 가져오기는 대개 'GMT Standard Time'과 같은 Windows 방식 시간대 이름 때문인데, 읽는 캘린더가 이를 인식하지 못해 UTC로 대체 처리하는 것이 원인입니다. 하루 어긋난 하루 종일 일정은 대개 VALUE=DATE가 필요했던 자정 타임스탬프이거나, DTEND가 배타적이기 때문에 다음 날이 아닌 마지막 날 자체에 종료일을 적어 놓은 경우입니다. ICS Maker는 기본적으로 부동 시간을 작성하며, 선택 시 IANA 시간대 이름을 지정하는 TZID를 작성합니다 — 다만 대부분의 주요 캘린더가 시간대 이름 자체로부터 해석할 수 있는 VTIMEZONE 블록은 포함하지 않습니다.

파일이 시간을 나타내는 세 가지 방식

부동 시간 — 시간대가 전혀 없음
DTSTART:20260815T090000. 어디에서 열든 아침 9시입니다. 현지 약속, 알림, 또는 읽는 사람 자신의 시계로 정의되는 모든 일에는 맞지만, 서로 다른 나라에 있는 두 사람이 만나야 하는 순간부터는 틀립니다.
UTC — 절대적인 순간
DTSTART:20260815T090000Z, 끝에 Z가 붙습니다. 여는 프로그램이 무엇이든 현지 시간으로 변환되는 한 순간입니다. 명확하지만, "런던 시각으로 10시"였다는 사실이 사라지므로 서머타임이 바뀌면 시간도 함께 움직입니다.
명명된 시간대 — 서머타임에도 살아남는 순간
DTSTART;TZID=Europe/London:20260815T090000. 반복 회의가 원하는 방식입니다. 오프셋이 그 아래에서 바뀌더라도 시리즈는 현지 시각 10시를 유지합니다. RFC 5545는 그 시간대의 오프셋을 정의하는 일치하는 VTIMEZONE 블록을 함께 요구합니다.

이 빌더는 기본적으로 첫 번째 방식을 작성하고, 목록에서 시간대를 선택하면 세 번째 방식을 작성합니다. 이 기본값은 의도된 것입니다. 9시로 잡은 치과 예약은 9시여야 하며, 파일을 만든 기기의 시간대를 그대로 붙이는 것이야말로 이를 읽는 사람에게 일정이 한 시간 어긋나 보이게 만드는 원인입니다.

이 도구는 TZID를 VTIMEZONE 블록 없이 작성하는데, 특이한 곳으로 파일을 보내기 전에 알아둘 만한 사실입니다. Apple 캘린더, Google 캘린더, Outlook, Thunderbird는 모두 IANA 시간대 데이터베이스를 내장하고 있어 이름만으로 Europe/London를 해석하므로, 이 블록은 읽는 쪽이 이미 알고 있는 내용을 수백 줄에 걸쳐 다시 적는 셈이 됩니다. 파일 자체에 정의된 시간대만 해석하는 엄격한 파서를 사용하는 경우가 이 절충이 통하지 않는 경우이므로, 그런 파서에 파일을 제공한다면 VTIMEZONE 블록을 직접 붙여 넣으세요.

잘못 도착한 파일 읽기

텍스트 편집기로 열어 DTSTART 줄을 확인하세요. 답은 항상 거기에 있습니다. 예상치 못한 오프셋과 함께 끝에 Z가 붙어 있다면, 보낸 사람이 여러분과 공유하지 않는 시간대에서 UTC로 변환했다는 뜻입니다. TZID이 Europe/London 대신 GMT Standard Time와 같은 이름을 사용한다면 이는 Microsoft Exchange 방식 표기이며, IANA 이름만 아는 캘린더는 UTC로 대체 처리할 수 있습니다 — 이것이 전형적인 한 시간 어긋난 가져오기입니다. TZID이 IANA 이름도 아니고 같은 파일 안의 VTIMEZONE 블록으로 정의되지도 않은 시간대를 지정한다면, 이는 모든 읽는 프로그램이 저마다 다르게 추측하는 경우이며, 흔히 UTC로 추측하는 경우가 많아 두 번째로 확인해야 할 사항입니다.

하루가 밀리는 하루 종일 일정

하루 종일 일정은 시간이 아니라 날짜입니다: DTSTART;VALUE=DATE:20260815. 대신 자정 타임스탬프로 작성되면 실제 순간이 되어버려서, 서쪽 방향으로의 변환이 하루 전날로 끌고 갑니다. 종료일은 또 다른 함정입니다 — 이는 배타적이므로, 15일 하루짜리 일정은 16일에 끝나며, 15일에 종료일을 적은 파일은 일부 캘린더에서 아예 표시되지 않습니다.

자주 묻는 질문

왜 내 캘린더 일정이 한 시간 어긋나 있나요?
거의 항상 서머타임 불일치가 원인입니다. 파일이 고정된 UTC 오프셋을 지정하거나, 읽는 캘린더가 인식하지 못하는 Windows 방식 시간대 이름을 사용하여 읽는 쪽이 UTC로 대체 처리하는 것입니다. DTSTART 줄을 확인하세요 — Z로 끝나면 절대 UTC 시간이며, TZID를 가지고 있다면 그 시간대는 Europe/Paris와 같은 IANA 이름으로 표기되어 있거나, 같은 파일 안의 VTIMEZONE 블록으로 정의되어 있어야 합니다. 주요 캘린더는 자체 시간대 데이터베이스 사본에서 IANA 이름을 해석하므로 그런 블록이 필요 없습니다.
시간대를 설정해야 하나요, 아니면 비워둬야 하나요?
일정이 현지 시계 시간으로 정의되는 경우 — 약속, 알림, 어디서든 9시에 시작하는 수업 — 라면 비워두세요. 통화, 웨비나, 방송처럼 다른 시간대의 참석자가 변환해야 하는 하나의 절대적인 순간에 일어나는 일정이라면 시간대를 설정하세요.
부동 시간이란 무엇인가요?
시간대도, 끝에 Z도 없이 작성된 날짜-시간으로, RFC 5545에 따르면 읽는 곳의 현지 시간으로 해석됩니다. 사람들이 예상하는 것보다 더 자주 옳은 선택이며, 서로 다른 시간대에 있는 두 사람이 한 순간에 합의해야 할 때는 틀린 선택입니다.
왜 내 하루 종일 일정이 잘못된 날짜에 표시되나요?
날짜 값이 아니라 자정 타임스탬프로 작성되었기 때문입니다. 진정한 하루 종일 일정은 시간이 전혀 없는 VALUE=DATE를 사용하므로 변환할 것이 없습니다. 또한 종료일이 배타적이라는 점도 기억하세요. 15일 하루짜리 일정은 DTEND가 16일입니다.