Я провёл более глубокое расследование и открыл PR для решения этой проблемы:
Проблема заключается не в часовом поясе сервера/контейнера, а в экспорте ICS. Экспортируемое событие использует IANA TZID, например Europe/Berlin, но в настоящее время не включает соответствующее определение VTIMEZONE, которое требуется клиентам, таким как Outlook, для надёжной интерпретации правил перехода на летнее время.
В PR добавлены определения VTIMEZONE для загрузок ICS с учётом часового пояса при сохранении существующих локальных значений DTSTART/DTEND.
Для примера из этой темы экспорт теперь включает правила применения CET/CEST для Europe/Berlin, поэтому:
DTSTART;TZID=Europe/Berlin:20260811T170000
может быть интерпретирован с правильным летним смещением UTC+2, а не с откатом Outlook к UTC+1.
Я также добавил покрытие для правил перехода на летнее время в Европе и Северной Америке, случай с фиксированным смещением и более необычные сезонные переходы, используемые в Africa/Casablanca.