Novas entradas de data em um tópico aparecem assim nos e-mails de notificação correspondentes:
2024-04-18T16:00:00Z UTC→2024-04-18T20:00:00Z UTC
Para o canal de publicação de e-mail, isso deve ser reformatado em uma informação de data legível para humanos com respeito ao fuso horário atual (neste caso: CET) da instância do discourse.
Instâncias do Discourse não têm “um fuso horário”. Sessões de usuários individuais têm.
OK, neste caso, a linha de data deve ser transformada para o fuso horário do usuário que recebe o e-mail de notificação
não 
Para o usuário que recebe, deve ser traduzido para o próprio fuso horário dele. Então, em vez de
UTC 2024-04-18, 16:00-20:00, deve ser exibido
CET 2024-04-18, 18:00-22:00
No calendário visual no topo do tópico, também tenho o horário correto
Não acho que seja um pedido razoável, pois exigirá pesquisa e processamento adicionais no lado do servidor para cada e-mail.
Não conheço o código aqui, mas esta é uma desvantagem possível, concordo.
Por outro lado, vemos a data correta no calendário visual no topo… Alguém que conheça o código deveria comentar sobre isso…
Não inspecionei o código, mas presumo que na web a data seja carregada igualmente do banco de dados para o cliente e analisada no lado do cliente via JS (que é uma opção que você não tem ao renderizar conteúdo no lado do cliente em um cliente de e-mail).
de fato, uma vez que o e-mail sai dos nossos servidores, não temos como ajustá-lo ao fuso horário do destinatário
houve alguma discussão anterior sobre isso: Discourse local dates need better presentation in emails
mudar para UTC foi uma melhoria em relação a não mostrar nenhum fuso horário, ou uma situação muito verbosa onde poderíamos mostrar 3 fusos horários para cada data… mas ainda não houve um acompanhamento para utilizar um fuso horário do site/usuário.
mesmo que sejam alguns fusos horários de distância, muitas pessoas provavelmente podem adivinhar melhor começando de um fuso horário específico em vez de UTC.
O UTC atual em e-mails é realmente muito ruim para o ‘usuário médio’, especialmente se você estiver do outro lado do mundo (ou seja, Nova Zelândia).
Muitos fóruns que usam Discourse estão enraizados em um único fuso horário; para esses, seria brilhante poder especificar o fuso horário padrão exibido nos e-mails para eles.
Para aqueles que abrangem fusos horários, sim, é mais complicado - evidenciado pelo motivo pelo qual ainda temos uma ‘solução temporária’ de 5 anos. Eu adoraria se alguém consideravelmente mais inteligente (ou pelo menos mais dedicado) do que eu resolvesse isso.
Concordo 100%. Temos um fórum localizado na Austrália e utilizamos tópicos fechados como listas de e-mail de facto. Quase todos estão localizados na Austrália e esperam que os horários das reuniões reflitam isso. O UTC nos e-mails é totalmente desconcertante para muitos usuários.
Não podemos pelo menos definir o fuso horário que é usado e permitir que cada instância escolha substituir ou não.
@j.jaffeux / @hugh / @lindsey o que vocês acham sobre:
Ele:
discourse_local_dates_email_timezone, que permite configurarEntão, em casos de um discourse altamente local, você o definiria para o fuso horário do país, o que torna os e-mails menos confusos.
Isso, infelizmente, é um pouco mais complicado, encaixar isso no pipeline não é trivial.
No entanto, como você apresentar a hora, por favor, por favor, por favor, sempre inclua o fuso horário escolhido!
Desculpe, não estou entendendo. Você pode explicar melhor o que quer dizer aqui?
No texto de exemplo, não há fuso horário. Estou dizendo que seria ruim se fosse literalmente o que seria usado. Eu sugeriria fortemente adicionar o descritor de fuso horário apropriado de três ou quatro letras, ou o descritor de formato longo de país/cidade. O texto existente tem “UTC”, que é uma indicação inequívoca do que se quer dizer - o novo comportamento deveria ser pelo menos tão bom quanto isso.
Mesmo em um “discurso altamente local”, pode haver usuários em fusos horários adjacentes, pode haver mudanças de horário de verão, pode haver usuários viajando e acessando de longe.
Do mesmo PR 
discourse_local_dates_email_format:
default: "llll UTC"
Não é uma causa pela qual vou lutar, mas é muito difícil entender as datas agora, então fico mais feliz que NYC/Londres/Paris recebam algo um pouco menos confuso… mas é muito difícil criar um formato que agrade a todos.
Podemos manter o status quo padrão, no entanto.
O que acontece se eu alterar o discourse_local_dates_email_timezone para “Europe/Paris”, mas não atualizar o formato para “llll Europe/Paris”? Isso fará com que a hora seja convertida para o horário de Paris, mas ainda exiba “UTC” após ela?
Sim, é isso que acontecerá, as configurações estão interligadas, você tem que mudar ambas.
Anteriormente à minha PR, nós codificamos o texto “UTC”, então isso nem sequer era configurável.
Isso me parece propenso a erros. É possível mostrar automaticamente o fuso horário selecionado em vez de esperar que o administrador atualize o formato manualmente? Usar "llll z" como padrão para discourse_local_dates_email_format funcionaria?
Ótima sacada Moin 
funcionou, atualizei meu PR