Les nouvelles entrées de date dans un sujet apparaissent comme ceci dans les courriels de notification correspondants :
2024-04-18T16:00:00Z UTC→2024-04-18T20:00:00Z UTC
Pour le canal de publication de courriel, ceci devrait être reformatté en une information de date lisible par l’homme en tenant compte du fuseau horaire actuel (dans ce cas : CET) de l’instance Discourse.
Les instances Discourse n’ont pas « de fuseau horaire ». Les sessions d’utilisateurs individuels en ont.
OK, dans ce cas, la date limite doit être transformée dans le fuseau horaire de l’utilisateur qui reçoit l’e-mail de notification.
non 
Pour l’utilisateur qui reçoit, cela doit être traduit dans son propre fuseau horaire. Donc, au lieu de
UTC 2024-04-18, 16:00-20:00, il devrait lire
CET 2024-04-18, 18:00-22:00
Dans le calendrier visuel en haut du fil, j’ai aussi la bonne heure
Je ne pense pas que ce soit une demande raisonnable, car elle nécessitera une recherche et un traitement supplémentaires côté serveur pour chaque e-mail.
Je ne connais pas le code ici, mais c’est un inconvénient possible, je suis d’accord.
D’un autre côté, nous voyons la date correcte dans le calendrier visuel en haut… Quelqu’un qui connaît le code devrait commenter cela…
Je n’ai pas inspecté le code, mais je suppose que sur le web, la date est chargée de manière égale de la base de données vers le client et est analysée côté client via js (ce qui est une option que vous n’avez pas lorsque vous rendez le contenu côté client dans un client de messagerie).
en effet, une fois que l’e-mail quitte nos serveurs, nous n’avons aucun moyen de l’ajuster au fuseau horaire du destinataire
il y a eu une discussion précédente à ce sujet : Discourse local dates need better presentation in emails
passer à l’UTC était une amélioration par rapport à ne pas afficher de fuseau horaire, ou une situation très verbeuse où nous pourrions afficher 3 fuseaux horaires pour chaque date… mais il n’y a toujours pas eu de suivi pour utiliser un fuseau horaire de site/utilisateur.
Même si ce n’est qu’à quelques fuseaux horaires, beaucoup de gens peuvent probablement faire une meilleure estimation en partant d’un fuseau horaire spécifique plutôt que de l’UTC.
L’heure UTC actuelle dans les e-mails est vraiment très mauvaise pour l’« utilisateur moyen », surtout s’il se trouve à l’autre bout du monde (par exemple, en Nouvelle-Zélande).
De nombreux forums utilisant Discourse sont ancrés dans un fuseau horaire unique ; pour ceux-là, il serait formidable de pouvoir spécifier le fuseau horaire par défaut affiché dans les e-mails.
Pour ceux qui couvrent plusieurs fuseaux horaires, oui, c’est plus compliqué - comme en témoigne la raison pour laquelle nous avons toujours une « solution temporaire » vieille de 5 ans. J’adorerais que quelqu’un de considérablement plus intelligent (ou du moins plus dévoué) que moi résolve ce problème.
Je suis absolument d’accord à 100 %. Nous avons un forum situé en Australie et nous utilisons des sujets fermés comme listes de diffusion de facto. Presque tout le monde est situé en Australie et s’attend à ce que les heures de réunion le reflètent. L’heure UTC dans les e-mails est totalement déroutante pour de nombreux utilisateurs.
Ne pouvons-nous au moins pas définir le fuseau horaire utilisé et permettre à chaque instance de choisir de le remplacer ou non.
@j.jaffeux / @hugh / @lindsey qu’en pensez-vous :
Il :
discourse_local_dates_email_timezone qui permet de configurerAinsi, dans le cas d’un discourse très localisé, vous le définiriez sur le fuseau horaire du pays, ce qui rendrait les e-mails moins déroutants.
Ceci est malheureusement un peu plus compliqué, l’intégrer dans le pipeline n’est pas trivial.
Quelle que soit la manière dont vous présentez l’heure, veuillez, s’il vous plaît, toujours inclure le fuseau horaire choisi !
Désolé, je ne comprends pas, pouvez-vous développer ce que vous voulez dire ici ?
Dans le texte de l’exemple, il n’y a pas de fuseau horaire. Je dis que ce serait une mauvaise chose si c’était littéralement ce qui serait utilisé. Je suggérerais fortement d’ajouter le descripteur de fuseau horaire approprié de trois ou quatre lettres, ou le descripteur de ville/pays en toutes lettres. Le texte existant contient « UTC », ce qui est une indication sans ambiguïté de ce qui est voulu - le nouveau comportement devrait être au moins aussi bon que cela.
Même dans un « discours très local », il peut y avoir des utilisateurs dans des fuseaux horaires adjacents, il peut y avoir des changements d’heure d’été, il peut y avoir des utilisateurs en déplacement accédant depuis l’étranger.
Du même PR 
discours_local_dates_email_format:
défaut: "llll UTC"
Ce n’est pas une bataille pour moi, mais il est très difficile de comprendre les dates maintenant, donc je suis plus heureux que NYC/Londres/Paris obtiennent quelque chose d’un peu moins déroutant… mais il est très difficile de trouver un format qui convienne à tout le monde.
Nous pouvons cependant conserver le statu quo par défaut.
Que se passe-t-il si je change discourse_local_dates_email_timezone en « Europe/Paris » mais que je ne mets pas à jour le format en « lllll Europe/Paris » ? Cela provoquera-t-il la conversion de l’heure en heure de Paris mais affichera-t-il toujours « UTC » après ?
Oui, c’est ce qui se passera, les paramètres sont entrelacés, vous devez changer les deux.
Avant mon PR, nous avions codé en dur le texte « UTC », donc ce n’était même pas configurable.
Cela me semble sujet aux erreurs. Est-il possible d’afficher automatiquement le fuseau horaire sélectionné au lieu de demander à l’administrateur de mettre à jour le format manuellement ? Est-ce que l’utilisation de "llll z" comme valeur par défaut pour discourse_local_dates_email_format fonctionnerait ?
Excellente trouvaille Moin 
ça fonctionne, j’ai mis à jour ma PR