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 instances do not have “a timezone”. Individual user sessions do.
OK, in this case, the date line should be transformed into the timezone of the user who receives the notification e-mail
nope 
For the receiving user, it should be translated into his own timezone. So, instead of
UTC 2024-04-18, 16:00-20:00 it should read
CET 2024-04-18, 18:00-22:00
In the visual calendar on top of the thread I also have the correct time
I don’t think that is a reasonable ask, as it will require additional individual look-up and processing server side for each mail
I dont know the code here, but this is a possible disadvantage, I agree.
On the other had, we see the correct date in the visual calendar on top … Someone who knows the code, should comment on this …
Haven’t inspected the code but I presume that on the web, the date loads equally from DB to client and is parsed client side via js (which is an option you don’t have when you render content client side in a mail client)
indeed, once the email leaves our servers we have no way to adjust to the recipients timezone
there was some previous discussion on this: Discourse local dates need better presentation in emails
switching to UTC was an improvement over not showing any timezone, or a very verbose situation where we might show 3 timezones for every date… but there still hasn’t been a follow-up to utilize a site/user timezone.
Even if it’s a few timezones away, many people can probably take a better guess when starting from a specific timezone rather than UTC.
The current UTC in emails is really really awful for the ‘average user’, especially if you are on the opposite side of the world (i.e. New Zealand).
Many forums using Discourse are rooted in a single Timezone; for those, it would work brilliantly to be able to specify the default timezone displayed in emails for them.
For those that span timezones, yup it is curlier - evidenced by why we still have a 5 year old ‘temporary’ fix. I’d love it if someone considerably cleverer (or at least more dedicated) than me works this out.
Absolutely agree 100%. We have a forum that is located in Australia and utilise closed topics as de-facto mailing lists. Almost everyone is located in Australia and expect the meeting times to reflect that. UTC in emails is utterly baffling for many users.
Can’t we at least set the timezone that is used and allow each instance to choose to override or not.
@joffreyjaffeux / @hugh / @lindsey how do you feel about:
It:
discourse_local_dates_email_timezone which allows configuringSo in cases of a highly local discourse you would set it to the countries timezone, which leaves emails less confusing.
This unfortunately is a bit more complicated, fitting this into the pipeline is not trivial.
However you present the time, please please please always include the chosen timezone!
Sorry I am not following, can you expand on what you mean here?
In the example text, there is no timezone. I’m saying that would be bad, if that’s literally what would be used. I’d strongly suggest adding the appropriate three or four letter timezone descriptor, or the country/city longform descriptor. The existing text has “UTC” which is an unambiguous indication of what’s meant - the new behaviour ought to be at least as good as that.
Even in a “highly local discourse” there may well be users in adjacent timezones, there may be daylight saving shifts, there may be users travelling and accessing from afar.
From the same PR 
discourse_local_dates_email_format:
default: "llll UTC"
Not a hill I will die on, but it is very hard to understand the dates now, so I am happier that NYC/London/Paris get something slightly less confusing… but it is very hard to come up with format that wins for everyone.
We can keep default status-quo though
What happens if I change the discourse_local_dates_email_timezone to “Europe/Paris” but I don’t update the format to “llll Europe/Paris”? Will that cause the time to be converted to Paris time but still display “UTC” after it?
Yes this is what will happen, the settings are intertwined, you got to change both.
Previous to my PR we hardcoded the text “UTC”, so this was not even configurable.
That seems error-prone to me. Is it possible to automatically show the selected timezone instead of expecting the admin to update the format manually? Would using "llll z" as the default for discourse_local_dates_email_format work?
Great catch Moin 
it works updated my PR