Exportação ICS de calendário/evento: hora incorreta (+1 h) ao importar no Outlook com TZID=Europe/Berlin

Versão: Discourse 2026.1.5 (ESR), plugin discourse-calendar

Resumo
Novos eventos criados com um fuso horário definido (timezone="Europe/Berlin" e showLocalTime="true") exibem o horário incorreto, com +1 hora de diferença, ao baixar o arquivo .ics e importá-lo no Outlook (Windows). O horário está correto no próprio fórum. Apenas novos eventos são afetados, ou seja, a importação via arquivo .ics.

Reprodução

  1. Crie um evento (hoje, no horário de verão CEST/UTC+2): 17:00 – 19:15 horário de Berlim.
[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. “Adicionar ao calendário” → baixar o arquivo .ics.
  2. Importar o arquivo no Outlook.

Esperado: 11.08.2026, 17:00 – 19:15
Real: 11.08.2026, 18:00 – 20:15 (+1 hora)

Conteúdo do ICS (relevante):

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

(O arquivo não contém um bloco VTIMEZONE para Europe/Berlin.)

Análise / Causa suspeita
A exportação especifica o horário localmente com TZID=Europe/Berlin (nome IANA) em vez de UTC (...Z). O Outlook não entende os nomes de fuso horário IANA (usa identificadores do Windows, como “W. Europe Standard Time”) e, sem uma definição de VTIMEZONE, recorre ao deslocamento fixo UTC+1 (CET/horário de inverno). Durante o horário de verão (CEST = UTC+2), isso resulta em exatamente +1 hora. Verificação cruzada: importar o mesmo arquivo no Google Calendar (que entende fusos horários IANA nativamente) mostra o horário correto de 17:00.

Sugestão: a exportação ICS deve usar carimbos de data/hora UTC com Z ou gerar um bloco VTIMEZONE completo, incluindo as regras de horário de verão (veja também a discussão sobre conformidade com a especificação ICS em LOCATION não está disponível na exportação ICS completa).

Observação adicional: Quando o mesmo evento é criado sem timezone=/showLocalTime, o .ics exportado usa UTC e o Outlook mostra +2 horas (já que 17:00 UTC = 19:00 CEST). Este é o comportamento documentado do UTC, mas ilustra ainda mais que o tratamento de fuso horário na exportação ICS é confuso para usuários que esperam horários locais.

Para comparação, tenho executado meu host e container de aplicativo Discourse no fuso horário local IANA em vez de UTC, devido ao comportamento anterior do fuso horário do calendário.

Meu host está configurado com:

timedatectl set-timezone Europe/London

e meu app.yml contém:

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

Isso significa que tanto meu host quanto o container Discourse usam Europe/London, incluindo a mudança automática GMT/BST.

Pode valer a pena testar o equivalente com Europe/Berlin em sua instalação para ver se a importação resultante do .ics no Outlook está correta:

timedatectl set-timezone Europe/Berlin

e, na seção run:,

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

Gostaria de saber se isso altera a importação do seu evento de 17:00 em Berlim, de 18:00 para o esperado 17:00.

Se sim, isso sugeriria que o fuso horário do Discourse/container está influenciando a exportação; se não, a falta de VTIMEZONE/manipulação do Outlook provavelmente é independente do fuso horário do servidor.