Resumen
Los nuevos eventos creados con una zona horaria establecida (timezone="Europe/Berlin" y showLocalTime="true") muestran una hora incorrecta con +1 hora al descargar el archivo .ics e importarlo en Outlook (Windows). La hora es correcta en el propio foro. Solo se ven afectados los nuevos eventos, es decir, la importación mediante el archivo .ics.
Reproducción
Crear un evento (hoy, en horario de verano CEST/UTC+2): 17:00 – 19:15 hora de Berlín.
(El archivo no contiene un bloque VTIMEZONE para Europe/Berlin.)
Análisis / Causa sospechada
La exportación especifica la hora localmente con TZID=Europe/Berlin (nombre IANA) en lugar de UTC (...Z). Outlook no entiende los nombres de zonas horarias IANA (utiliza identificadores de Windows como «W. Europe Standard Time») y, sin una definición VTIMEZONE, vuelve al desplazamiento fijo UTC+1 (CET/hora de invierno). Durante la hora de verano (CEST = UTC+2) esto provoca exactamente +1 hora. Comprobación cruzada: importar el mismo archivo en Google Calendar (que entiende las zonas horarias IANA de forma nativa) muestra la correcta 17:00.
Sugerencia: la exportación ICS debería utilizar marcas de tiempo UTC con Z o generar un bloque VTIMEZONE completo que incluya las reglas de horario de verano (véase también la discusión sobre el cumplimiento de la especificación ICS en LOCATION no está disponible en la exportación ICS completa).
Observación adicional: Cuando el mismo evento se crea sintimezone=/showLocalTime, el .ics exportado utiliza UTC y Outlook muestra +2 horas (ya que 17:00 UTC = 19:00 CEST). Este es el comportamiento UTC documentado, pero ilustra aún más que el manejo de las zonas horarias en torno a la exportación ICS resulta confuso para los usuarios que esperan horas locales.
Para comparar, he estado ejecutando mi host de Discourse y el contenedor de la aplicación en la zona horaria IANA local en lugar de UTC debido al comportamiento anterior de las zonas horarias del calendario.
Esto significa que tanto mi host como el contenedor de Discourse utilizan Europe/London, incluido el cambio automático entre GMT y BST.
Podría valer la pena probar lo equivalente con Europe/Berlin en tu instalación para ver si la importación resultante en .ics funciona correctamente en Outlook:
Me gustaría saber si eso cambia la importación de tu evento de Berlín a las 17:00, pasando de las 18:00 a las 17:00 esperadas.
Si es así, eso sugeriría que la zona horaria de Discourse/contenedor está influyendo en la exportación; si no es así, la falta de VTIMEZONE o el manejo de Outlook probablemente sea independiente de la zona horaria del servidor.
Nosotros también estamos experimentando exactamente este problema.
Reproducción:
Evento creado con timezone="Europe/Berlin" y showLocalTime="true", durante el CEST (horario de verano).
Se descargó el archivo .ics a través de “Agregar al calendario” y se importó en Outlook.
Resultado actual: El evento se muestra con una hora de desfase (por ejemplo, las 17:00 hora de Berlín aparecen como las 18:00 en Outlook). Resultado esperado: El evento debería mostrarse a las 17:00, tal como se ingresó.
Podemos confirmar que esto ocurre de manera consistente, no de forma intermitente, para los eventos que ocurren durante el CEST. Otros eventos fuera del CEST no se ven afectados.
Sería realmente agradable ver este problema resuelto, ya que nuestros usuarios pueden ser muy sensibles a las fallas
El problema reside en la exportación ICS, no en la zona horaria del servidor/contenedor. El evento exportado utiliza un TZID IANA, como Europe/Berlin, pero actualmente no incluye la definición correspondiente de VTIMEZONE que clientes como Outlook necesitan para interpretar de manera fiable las reglas de horario de verano.
La PR añade definiciones de VTIMEZONE a las descargas ICS con zona horaria, manteniendo al mismo tiempo los valores locales existentes de DTSTART/DTEND.
Para el ejemplo de este tema, la exportación ahora incluye las observancias de CET/CEST para Europe/Berlin, de modo que:
DTSTART;TZID=Europe/Berlin:20260811T170000
puede interpretarse con el correcto desplazamiento de verano UTC+2, en lugar de que Outlook recurra a UTC+1.
También he añadido cobertura para las reglas de horario de verano de Europa y Norteamérica, un caso de desplazamiento fijo y las transiciones estacionales más inusuales utilizadas por Africa/Casablanca.
