캘린더/이벤트 ICS 내보내기: TZID=Europe/Berlin으로 Outlook에 가져올 때 시간 오류(+1시간)

기여 버그
1

버전: Discourse 2026.1.5 (ESR), discourse-calendar 플러그인

요약
특정 시간대(timezone="Europe/Berlin" 및 showLocalTime="true")가 설정된 상태로 생성된 새 이벤트는 .ics 파일을 다운로드하여 **Outlook (Windows)**에 가져올 때 +1시간의 오차가 있는 잘못된 시간을 표시합니다. 포럼 자체에서는 시간이 올바르게 표시됩니다. 영향은 .ics 파일 통한 가져오기인 새 이벤트에만 해당됩니다.

재현 방법

  1. 이벤트를 생성합니다(오늘, 서머타임 CEST/UTC+2 적용 중): 베를린 시간 오후 5:00 – 오후 7:15.
[event start="2026-08-11 17:00" status="public" name="testevent 2" timezone="Europe/Berlin" showLocalTime="true" end="2026-08-11 19:15"]
[/event]
  1. “캘린더에 추가” → .ics 파일 다운로드.
  2. 파일을 Outlook에 가져옵니다.

기대 결과: 2026년 8월 11일, 17:00 – 19:15
실제 결과: 2026년 8월 11일, 18:00 – 20:15 (+1시간)

ICS 내용 (관련 부분):

DTSTART;TZID=Europe/Berlin:20260811T170000
DTEND;TZID=Europe/Berlin:20260811T191500

(해당 파일에는 Europe/Berlin에 대한 VTIMEZONE 블록이 포함되어 있지 않습니다.)

분석 / 의심되는 원인
내보내기 과정에서 UTC(...Z)가 아닌 IANA 이름인 TZID=Europe/Berlin으로 지역 시간이 지정됩니다. Outlook은 IANA 시간대 이름(“W. Europe Standard Time”과 같은 Windows 식별자를 사용)을 이해하지 못하며, VTIMEZONE 정의가 없으면 고정 오프셋인 **UTC+1 (CET/동계 시간)**으로 폴백합니다. 서머타임 기간(CEST = UTC+2)에는 이로 인해 정확히 +1시간의 오차가 발생합니다. 교차 검증: 동일한 파일을 Google Calendar(IANA 시간대를 기본적으로 이해함)에 가져오면 17:00이 올바르게 표시됩니다.

제안: ICS 내보내기에서는 Z가 포함된 UTC 타임스탬프를 사용하거나 DST 규칙을 포함한 완전한 VTIMEZONE 블록을 생성해야 합니다(ICS 스펙 준수에 대한 논의는 LOCATION is not available in full ICS export 참조).

추가 관찰 사항: timezone=/showLocalTime 없이 동일한 이벤트를 생성하면, 내보내진 .ics 파일은 UTC를 사용하며 Outlook에서는 +2시간이 표시됩니다(17:00 UTC = 19:00 CEST). 이는 문서화된 UTC 동작이지만, 지역 시간을 기대하는 사용자에게 ICS 내보내기 주변의 시간대 처리가 혼란스럽다는 점을 더 잘 보여줍니다.

2개의 좋아요
3

비교를 위해, 이전 달력 시간대 동작 문제로 인해 저는 UTC가 아닌 로컬 IANA 시간대를 사용하여 Discourse 호스트와 앱 컨테이너를 실행해 왔습니다.

저의 호스트는 다음과 같이 설정되어 있습니다:

timedatectl set-timezone Europe/London

그리고 제 app.yml에는 다음 내용이 포함되어 있습니다:

- exec: ln -fs /usr/share/zoneinfo/Europe/London /etc/localtime
- exec: dpkg-reconfigure --frontend noninteractive tzdata

이로 인해 제 호스트와 Discourse 컨테이너 모두 Europe/London 시간대를 사용하며, GMT/BST의 자동 변경도 포함됩니다.

귀하의 설치 환경에서는 Europe/Berlin으로 동일한 설정을 테스트하여 결과적으로 생성된 .ics 파일이 Outlook에 올바르게 가져와지는지 확인해 보시는 것이 좋을 수 있습니다:

timedatectl set-timezone Europe/Berlin

그리고 run: 섹션에서,

- exec: ln -fs /usr/share/zoneinfo/Europe/Berlin /etc/localtime
- exec: dpkg-reconfigure --frontend noninteractive tzdata

이렇게 했을 때, 베를린 17:00 이벤트가 18:00으로 가져와지는 것이 아니라 예상대로 17:00으로 가져와지는지 변화가 있는지 궁금합니다.

변화가 있다면, 이는 Discourse/컨테이너 시간대가 내보내기에 영향을 미치고 있음을 시사합니다. 반면, 변화가 없다면, 누락된 VTIMEZONE/Outlook 처리 문제는 서버 시간대와 무관할 가능성이 높습니다.

4

저희도 정확히 같은 문제를 겪고 있습니다.

재현 방법:

  • timezone="Europe/Berlin" 및 showLocalTime="true"로 이벤트 생성 (서머타임인 CEST 기간 중).
  • "캘린더에 추가"를 통해 .ics 파일을 다운로드하여 Outlook에 가져옴.

실제 결과: 이벤트가 +1시간 차이가 나게 표시됩니다 (예: 베를린 시간 17:00이 Outlook에서 18:00으로 표시됨).
기대 결과: 입력한 대로 17:00으로 표시되어야 합니다.

CEST 기간에 발생하는 이벤트에서 일관되게 발생하며, 간헐적인 문제가 아님을 확인했습니다. CEST 기간 외의 다른 이벤트에는 영향이 없습니다.

사용자들이 오류에 매우 민감할 수 있으므로 이 문제가 수정되기를 진심으로 바랍니다. :see_no_evil_monkey:

5

이 문제를 추가로 조사했으며, 해결을 위한 PR을 열었습니다:

이 문제는 서버/컨테이너의 시간대가 아니라 ICS 내보내기 과정에서 발생합니다. 내보내진 이벤트는 Europe/Berlin과 같은 IANA TZID를 사용하지만, Outlook와 같은 클라이언트가 일광절약제(DST) 규칙을 안정적으로 해석하는 데 필요한 해당 VTIMEZONE 정의를 현재 포함하지 않고 있습니다.

해당 PR은 시간대 인식 ICS 다운로드에 VTIMEZONE 정의를 추가하는 동시에 기존 로컬 DTSTART/DTEND 값을 유지합니다.

이 토픽의 예시와 관련하여, 내보내기 시 Europe/Berlin에 대한 CET/CEST 적용 사항이 이제 포함되므로:

DTSTART;TZID=Europe/Berlin:20260811T170000

Outlook이 UTC+1로 폴백하는 대신 올바른 UTC+2 여름 오프셋으로 해석될 수 있습니다.

또한 유럽과 북미의 일광절약제 규칙, 고정 오프셋 사례, 그리고 Africa/Casablanca에서 사용되는 보다 이례적인 계절적 전환에 대한 테스트 커버리지도 추가했습니다.

1개의 좋아요