New date entries in a topic appear like this in the corresponding notification mails:
Nächstes Freifunk Treffen Makers Inn (noch unbestätigt)
2024-04-18T16:00:00Z UTC→2024-04-18T20:00:00Z UTC
For the mail publication channel, this should be reformatted into a human-readable date information with respect to the current timezone (in this case: CET) of the discourse instance.
Discourse-Instanzen haben keine „Zeitzone“. Individuelle Benutzersitzungen haben eine.
OK, in diesem Fall sollte die Datumszeile in die Zeitzone des Benutzers umgewandelt werden, der die Benachrichtigungs-E-Mail erhält.
nein 
Für den empfangenden Benutzer sollte es in seine eigene Zeitzone übersetzt werden. Anstatt also
UTC 2024-04-18, 16:00-20:00 sollte es lauten
CET 2024-04-18, 18:00-22:00
Im visuellen Kalender oben im Thread habe ich auch die richtige Zeit
Ich glaube nicht, dass das eine vernünftige Forderung ist, da sie auf der Serverseite für jede E-Mail eine zusätzliche individuelle Nachschlage- und Verarbeitungsanforderung erfordert.
Ich kenne den Code hier nicht, aber das ist ein möglicher Nachteil, da stimme ich zu.
Auf der anderen Seite sehen wir das richtige Datum im visuellen Kalender oben … Jemand, der den Code kennt, sollte sich dazu äußern …
Ich habe den Code nicht geprüft, aber ich gehe davon aus, dass das Datum im Web gleichermaßen von der DB zum Client geladen und clientseitig über JS geparst wird (was eine Option ist, die Sie nicht haben, wenn Sie Inhalte clientseitig in einem Mail-Client rendern).
in der Tat, sobald die E-Mail unsere Server verlassen hat, können wir sie nicht mehr an die Zeitzone des Empfängers anpassen
es gab bereits einige Diskussionen dazu: Discourse local dates need better presentation in emails
der Wechsel zu UTC war eine Verbesserung gegenüber der Nichtanzeige einer Zeitzone oder einer sehr umständlichen Situation, in der wir möglicherweise 3 Zeitzonen für jedes Datum angezeigt hätten … aber es gab noch keine Nachverfolgung zur Nutzung einer Website-/Benutzerzeitzone.
Selbst wenn es nur ein paar Zeitzonen entfernt ist, können viele Leute wahrscheinlich eine bessere Vermutung anstellen, wenn sie von einer bestimmten Zeitzone ausgehen, anstatt von UTC.
Die aktuelle UTC in E-Mails ist für den „durchschnittlichen Benutzer“ wirklich, wirklich schrecklich, besonders wenn man sich auf der anderen Seite der Welt befindet (z. B. in Neuseeland).
Viele Foren, die Discourse verwenden, sind in einer einzigen Zeitzone verwurzelt; für diese wäre es brillant, die Standardzeitzone festlegen zu können, die in E-Mails für sie angezeigt wird.
Für diejenigen, die sich über Zeitzonen erstrecken, ja, es ist komplizierter – belegt durch den Grund, warum wir immer noch eine 5 Jahre alte „temporäre“ Lösung haben. Ich würde es lieben, wenn jemand, der erheblich klüger (oder zumindest engagierter) als ich ist, dies herausfinden würde.
Absolut einverstanden, zu 100 %. Wir haben ein Forum, das sich in Australien befindet, und nutzen geschlossene Themen als De-facto-Mailinglisten. Fast jeder befindet sich in Australien und erwartet, dass die Besprechungszeiten dies widerspiegeln. UTC in E-Mails ist für viele Benutzer völlig verwirrend.
Können wir nicht zumindest die verwendete Zeitzone festlegen und jeder Instanz erlauben, diese zu überschreiben oder nicht.
@j.jaffeux / @hugh / @lindsey Wie steht ihr zu:
Es:
discourse_local_dates_email_timezone hinzu, das die Konfiguration derIn Fällen eines stark lokalen Discourse würden Sie es auf die Zeitzone des Landes einstellen, was E-Mails weniger verwirrend macht.
Das ist leider etwas komplizierter, die Integration in die Pipeline ist nicht trivial.
Wie auch immer Sie die Zeit angeben, bitte, bitte, bitte geben Sie immer die gewählte Zeitzone an!
Entschuldigung, ich verstehe das nicht ganz. Könnten Sie das bitte näher erläutern?
Im Beispieltext gibt es keine Zeitzone. Ich sage, das wäre schlecht, wenn das buchstäblich verwendet würde. Ich würde dringend empfehlen, den entsprechenden drei- oder vierstelligen Zeitzonen-Deskriptor oder den Langform-Deskriptor des Landes/der Stadt hinzuzufügen. Der vorhandene Text enthält “UTC”, was eine eindeutige Angabe dessen ist, was gemeint ist - das neue Verhalten sollte mindestens genauso gut sein.
Selbst in einem “sehr lokalen Diskurs” kann es Benutzer in benachbarten Zeitzonen geben, es kann Sommerzeitverschiebungen geben, es kann Benutzer geben, die reisen und aus der Ferne zugreifen.
Vom selben PR 
discourse_local_dates_email_format:
default: "llll UTC"
Das ist kein Thema, für das ich kämpfen werde, aber es ist jetzt sehr schwer, die Daten zu verstehen. Ich bin also glücklicher, dass NYC/London/Paris etwas weniger Verwirrendes bekommen… aber es ist sehr schwer, ein Format zu finden, das für alle passt.
Wir können aber den Standard-Status quo beibehalten.
Was passiert, wenn ich discourse_local_dates_email_timezone in „Europe/Paris“ ändere, aber das Format nicht in „llll Europe/Paris“ ändere? Führt dies dazu, dass die Zeit in Pariser Zeit umgerechnet wird, aber danach immer noch „UTC“ angezeigt wird?
[Zitat=“Moin, Beitrag:17, Thema:299937”]
Wird das dazu führen, dass die Zeit in Pariser Zeit umgerechnet wird, aber trotzdem “UTC” dahinter angezeigt wird?
[/Zitat]
Ja, genau das wird passieren, die Einstellungen sind miteinander verbunden, du musst beides ändern.
Vor meinem PR (Pull Request) haben wir den Text “UTC” fest einprogrammiert, sodass dies nicht einmal konfigurierbar war.
Das scheint mir fehleranfällig zu sein. Wäre es möglich, die ausgewählte Zeitzone automatisch anzuzeigen, anstatt zu erwarten, dass der Administrator das Format manuell aktualisiert? Würde die Verwendung von "llll z" als Standard für discourse_local_dates_email_format funktionieren?
Guter Fang Moin 
es funktioniert, habe meinen PR aktualisiert