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

[Michael_D]

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]

2. “Adicionar ao calendário” → baixar o arquivo .ics.
3. 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.

[Ethsim2 (Ethan)]

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.

[Tonja]

Também estamos enfrentando exatamente esse problema.

Reprodução:

• Evento criado com timezone="Europe/Berlin" e showLocalTime="true", durante o horário de verão (CEST).
• Baixamos o arquivo .ics via “Adicionar ao calendário” e importamos no Outlook.

Resultado atual: O evento aparece com 1 hora de diferença (ex.: 17:00 no horário de Berlim aparece como 18:00 no Outlook).
Resultado esperado: O evento deveria exibir 17:00, conforme digitado.

Podemos confirmar que isso ocorre de forma consistente, e não intermitente, para eventos que acontecem durante o CEST. Outros eventos fora do período de CEST não são afetados.

Ficaria muito feliz em ver esse problema corrigido, já que nossos usuários podem ser muito sensíveis a falhas

[Ethsim2 (Ethan)]

Investiguei o problema com mais detalhes e abri um PR para tratá-lo:

https://github.com/discourse/discourse/pull/43168

O problema está na exportação ICS, e não no fuso horário do servidor/contêiner. O evento exportado usa um TZID da IANA, como Europe/Berlin, mas atualmente não inclui a definição correspondente de VTIMEZONE que clientes como o Outlook precisam para interpretar as regras de horário de verão de forma confiável.

O PR adiciona definições de VTIMEZONE aos downloads ICS com suporte a fuso horário, mantendo os valores locais existentes de DTSTART/DTEND.

No exemplo deste tópico, a exportação agora inclui as observações de CET/CEST para Europe/Berlin, de modo que:

DTSTART;TZID=Europe/Berlin:20260811T170000

pode ser interpretado com o correto deslocamento de verão UTC+2, em vez de o Outlook recorrer ao UTC+1.

Também adicionei cobertura para regras de horário de verão da Europa e da América do Norte, um caso de deslocamento fixo e as transições sazonais mais incomuns usadas por Africa/Casablanca.

[Ethsim2 (Ethan)]

@Michael_D @Tonja uma correção foi mesclada e deve chegar em latest em breve

[tannerabread (Bannon Tanner)]

Eu estava acompanhando o pipeline enquanto você digitava. A correção já está na latest. Obrigado pela sua contribuição, @Ethsim2!

[Tonja]

Muito obrigado @Ethsim2 e @tannerabread