トピックの新しい日付エントリは、対応する通知メールで次のように表示されます。
> Nächstes Freifunk Treffen Makers Inn (noch unbestätigt)
>
> 2024-04-18T16:00:00Z UTC→2024-04-18T20:00:00Z UTC
メールの公開チャネルでは、これを、Discourseインスタンスの現在のタイムゾーン（この場合はCET）を考慮して、人間が読める日付情報に再フォーマットする必要があります。
「いいね！」 4
ディスコースインスタンスには「タイムゾーン」はありません。個々のユーザーセッションにあります。
「いいね！」 1
この場合、日付行は通知メールを受信するユーザーのタイムゾーンに変換する必要があります。
「いいね！」 1
- イベントおよび/またはイベント作成者のタイムゾーンであるべきです。
- より見やすくフォーマットされるべきです。例えば、「2024-04-18T16:00:00Z UTC→2024-04-18T20:00:00Z UTC」ではなく、「UTC 2024-04-18、16:00-20:00」のように表示されるべきです。
「いいね！」 1
いいえ 
受信ユーザーにとっては、自身のタイムゾーンに翻訳されるべきです。したがって、
UTC 2024-04-18、16:00-20:00 の代わりに
CET 2024-04-18、18:00-22:00
と表示されるべきです。
スレッド上部のビジュアルカレンダーにも正しい時間が表示されています。
「いいね！」 3
それは無理なお願いだと思います。メールごとに個別に検索し、サーバー側で処理する必要が出てくるためです。
コードはわかりませんが、これは潜在的な欠点であり、同意します。
一方で、上部のビジュアルカレンダーには正しい日付が表示されています…コードを知っている人がコメントすべきです…
コードは確認していませんが、Webでは日付がデータベースからクライアントに同じようにロードされ、JavaScriptでクライアント側で解析されると推測しています（これは、メールクライアントでコンテンツをクライアント側でレンダリングする場合には選択できないオプションです）。
メールが当社のサーバーから送信されると、受信者のタイムゾーンに合わせる方法はありません。
この件については、以前にも議論がありました。Discourse local dates need better presentation in emails
UTCに切り替えたことは、タイムゾーンを表示しない、または1つの日付に対して3つのタイムゾーンを表示する可能性のある非常に冗長な状況よりも改善されました。しかし、サイト/ユーザーのタイムゾーンを活用するためのフォローアップはまだ行われていません。
たとえ数タイムゾーン離れていても、多くの人はUTCから始めるよりも、特定のタイムゾーンから開始する方がより良い推測ができるでしょう。
「いいね！」 5
メールでの現在のUTCは、「平均的なユーザー」にとって本当にひどいものです。特に、世界の反対側（ニュージーランドなど）にいる場合はなおさらです。\n\nDiscourseを使用している多くのフォーラムは単一のタイムゾーンに根ざしています。それらの場合、それらにとってメールに表示されるデフォルトのタイムゾーンを指定できると、非常にうまく機能するでしょう。\n\nタイムゾーンをまたぐものについては、はい、それはより複雑です。5年前の「一時的な」修正がまだある理由がそれを証明しています。私よりもかなり賢い（少なくともより献身的な）誰かがこれを解決してくれることを願っています。
「いいね！」 5
まったく同感です。オーストラリアに拠点を置くフォーラムがあり、クローズドトピックを事実上のメーリングリストとして利用しています。ほとんどのユーザーはオーストラリアに住んでおり、会議時間がそれを反映することを期待しています。メールでのUTCは、多くのユーザーにとってまったく不可解です。
少なくとも使用されるタイムゾーンを設定し、各インスタンスが上書きするかどうかを選択できるようにすることはできませんか。
「いいね！」 3
@j.jaffeux / @hugh / @lindsey これはどのように感じますか？
これは：
- デフォルトのメール形式をllll（例：2018年5月8日火曜日午前2時）に変更します
2018-05-08T00:00:00Z UTCから、目に優しくありません discourse_local_dates_email_timezoneを追加し、設定を可能にします
メールのデフォルトタイムゾーン- サイト設定のヘルプテキストを改善しました（形式/タイムゾーン）
したがって、高度にローカル化されたディスコースの場合、国のタイムゾーンに設定すると、メールの混乱が少なくなります。
残念ながら、これはもう少し複雑で、パイプラインに適合させるのは簡単ではありません。
「いいね！」 5
時間をどのように表示するにしても、選択したタイムゾーンを必ず含めてください！
「いいね！」 2
申し訳ありませんが、よく理解できません。ここで言っていることについて、もう少し詳しく説明していただけますか？
例のテキストにはタイムゾーンがありません。もしそれが文字通り使用されるなら、それは悪いことだと私は言っています。適切な3文字または4文字のタイムゾーン記述子、または国/都市の長形式記述子を追加することを強くお勧めします。既存のテキストには「UTC」という、それが何を意味するのかを曖昧さなく示すものがありますが、新しい動作は少なくともそれと同等に良いものであるべきです。
「非常にローカルなディスコース」であっても、隣接するタイムゾーンのユーザーがいる可能性、夏時間の変更がある可能性、旅行者が遠方からアクセスしている可能性などがあります。
「いいね！」 2
同じPRから 
discourse_local_dates_email_format:
default: "llll UTC"
これは私が譲れない主張ではありませんが、現在では日付の理解が非常に困難になっているため、NYC/London/Paris が少しでも混乱の少ないものを得られるなら、私はそちらの方が嬉しいです…しかし、全員にとって最良となるフォーマットを考案するのは非常に困難です。
ただし、デフォルトの現状維持を続けることも可能です。
「いいね！」 1
discourse_local_dates_email_timezone を「Europe/Paris」に変更し、フォーマットを「llll Europe/Paris」に更新しなかった場合、どうなりますか？時間はパリ時間に変換されますが、その後ろに「UTC」と表示されてしまいますか？
「いいね！」 2
[引用=“Moin, post:17, topic:299937”]
時間はパリ時間に変換されるのに、末尾にはまだ「UTC」と表示されるということですか？
[/quote]
はい、そうなります。設定が絡み合っているので、両方変更する必要があります。
私のPR以前は、「UTC」というテキストをハードコードしていたので、設定すらできませんでした。
「いいね！」 3
それは私にはエラーが発生しやすいように思えます。管理者が手動でフォーマットを更新するのではなく、選択されたタイムゾーンを自動的に表示することは可能ですか？ "llll z" を discourse_local_dates_email_format のデフォルトとして使用するとどうなりますか？
「いいね！」 5
素晴らしい指摘ですね、Moin 
動作しました。PRを更新しました。
「いいね！」 6