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.