Las nuevas entradas de fechas en un tema aparecen así en los correos de notificación correspondientes:
2024-04-18T16:00:00Z UTC→2024-04-18T20:00:00Z UTC
Para el canal de publicación de correo, esto debería reformatearse en una información de fecha legible por humanos con respecto a la zona horaria actual (en este caso: CET) de la instancia de Discourse.
Las instancias de Discourse no tienen “una zona horaria”. Las sesiones de usuario individuales sí la tienen.
OK, en este caso, la línea de fecha debe transformarse a la zona horaria del usuario que recibe el correo electrónico de notificación.
no 
Para el usuario receptor, debe traducirse a su propia zona horaria. Así que, en lugar de
UTC 2024-04-18, 16:00-20:00 debería decir
CET 2024-04-18, 18:00-22:00
En el calendario visual en la parte superior del hilo también tengo la hora correcta
No creo que sea una solicitud razonable, ya que requerirá una búsqueda y procesamiento adicional del lado del servidor para cada correo electrónico.
No conozco el código aquí, pero esta es una posible desventaja, estoy de acuerdo.
Por otro lado, vemos la fecha correcta en el calendario visual de arriba… Alguien que conozca el código debería comentar esto…
No he inspeccionado el código, pero supongo que en la web, la fecha se carga de la misma manera desde la base de datos al cliente y se analiza en el lado del cliente a través de js (que es una opción que no tienes cuando renderizas contenido en el lado del cliente en un cliente de correo electrónico).
De hecho, una vez que el correo electrónico sale de nuestros servidores, no tenemos forma de ajustarlo a la zona horaria del destinatario.
Hubo una discusión previa sobre esto: Discourse local dates need better presentation in emails
Cambiar a UTC fue una mejora con respecto a no mostrar ninguna zona horaria, o una situación muy verbosa en la que podríamos mostrar 3 zonas horarias para cada fecha… pero todavía no ha habido un seguimiento para utilizar una zona horaria del sitio/usuario.
Incluso si está a unas pocas zonas horarias de distancia, muchas personas probablemente puedan adivinar mejor partiendo de una zona horaria específica en lugar de UTC.
La hora UTC actual en los correos electrónicos es realmente, realmente terrible para el “usuario promedio”, especialmente si estás en el lado opuesto del mundo (es decir, Nueva Zelanda).
Muchos foros que usan Discourse están arraigados en una única zona horaria; para ellos, funcionaría brillantemente poder especificar la zona horaria predeterminada que se muestra en los correos electrónicos.
Para aquellos que abarcan zonas horarias, sí, es más complicado, como lo demuestra por qué todavía tenemos una “solución temporal” de 5 años. Me encantaría que alguien considerablemente más inteligente (o al menos más dedicado) que yo lo resuelva.
Absolutamente de acuerdo al 100%. Tenemos un foro que se encuentra en Australia y utilizamos temas cerrados como listas de correo de facto. Casi todos están ubicados en Australia y esperan que los horarios de las reuniones lo reflejen. La hora UTC en los correos electrónicos es completamente desconcertante para muchos usuarios.
¿No podemos al menos establecer la zona horaria que se utiliza y permitir que cada instancia elija anularla o no.
@j.jaffeux / @hugh / @lindsey ¿qué opinan sobre:
Esto:
discourse_local_dates_email_timezone, que permite configurar la zona horaria predeterminada en los correos electrónicosAsí, en casos de un discourse muy local, lo configurarías a la zona horaria del país, lo que hace que los correos electrónicos sean menos confusos.
Esto, desafortunadamente, es un poco más complicado, integrarlo en el pipeline no es trivial.
Sin embargo, como sea que presentes la hora, por favor, por favor, por favor, ¡siempre incluye la zona horaria elegida!
Lo siento, no lo entiendo, ¿puedes explicar mejor a quúe te refieres aquú?
En el texto de ejemplo, no hay zona horaria. Digo que eso sería malo, si eso es literalmente lo que se usaría. Sugeriría encarecidamente añadir el descriptor de zona horaria apropiado de tres o cuatro letras, o el descriptor de formato largo de país/ciudad. El texto existente tiene “UTC”, que es una indicación inequívoca de lo que se quiere decir; el nuevo comportamiento debería ser al menos tan bueno como ese.
Incluso en un “discurso muy local” puede haber usuarios en zonas horarias adyacentes, puede haber cambios de horario de verano, puede haber usuarios que viajan y acceden desde lejos.
Del mismo PR 
discourse_local_dates_email_format:
default: "llll UTC"
No es una batalla en la que vaya a morir, pero ahora es muy difícil entender las fechas, así que estoy más contento de que NYC/Londres/París obtengan algo un poco menos confuso… pero es muy difícil encontrar un formato que funcione para todos.
Sin embargo, podemos mantener el status quo por defecto.
¿Qué sucede si cambio discourse_local_dates_email_timezone a “Europe/Paris” pero no actualizo el formato a “llll Europe/Paris”? ¿Provocará que la hora se convierta a hora de París pero siga mostrando “UTC” después?
Sí, esto es lo que sucederá, la configuración está interconectada, tienes que cambiar ambas.
Antes de mi PR, codificamos el texto “UTC”, por lo que ni siquiera era configurable.
Eso me parece propenso a errores. ¿Es posible mostrar automáticamente la zona horaria seleccionada en lugar de esperar que el administrador actualice el formato manualmente? ¿Funcionaría usar "llll z" como valor predeterminado para discourse_local_dates_email_format?
Gran acierto Moin 
funciona, actualicé mi PR