Date line should be human-readable in mails

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

  1. It should be in the timezone of the event and/or event creator
  2. It should be more nicely formatted, ie instead of “2024-04-18T16:00:00Z UTC→2024-04-18T20:00:00Z UTC” it should read like “UTC 2024-04-18, 16:00-20:00”

nope :wink: 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.