在主题中新增的日期条目在相应的通知邮件中显示如下：
> Nächstes Freifunk Treffen Makers Inn (noch unbestätigt)
>
> 2024-04-18T16:00:00Z UTC→2024-04-18T20:00:00Z UTC
对于邮件发布渠道，这应该被重新格式化为人类可读的日期信息，并考虑到 Discourse 实例的当前时区（在本例中为：CET）。
4 个赞
Discourse 实例没有“时区”。单独的用户会话有。
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 个赞
我认为这不合理，因为它需要为每封邮件在服务器端进行额外的单独查找和处理。
我不知道这里的代码，但这可能是一个缺点，我同意。
另一方面，我们在顶部的可视化日历中看到了正确的日期……懂代码的人应该对此发表评论……
我还没有检查代码，但我推测在网络上，日期会同样地从数据库加载到客户端，并通过 JS 在客户端进行解析（当你在邮件客户端上客户端渲染内容时，这是你没有的选项）。
确实，一旦电子邮件离开我们的服务器，我们就无法将其调整为收件人的时区。
关于此问题之前有一些讨论：Discourse local dates need better presentation in emails
切换到 UTC 比不显示任何时区，或者显示非常冗长、可能为每个日期显示 3 个时区的情况有所改进……但仍未进行后续工作来利用站点/用户时区。
即使相差几个时区，许多人也可能比从 UTC 开始更容易猜测出准确时间。
5 个赞
电子邮件中当前的 UTC 对“普通用户”来说非常糟糕，尤其是如果您在世界的另一端（例如新西兰）。
许多使用 Discourse 的论坛都根植于单一时区；对于这些论坛，能够指定电子邮件中显示的默认时区将非常棒。
对于跨越时区的论坛，是的，这很棘手——正如我们仍然有一个 5 年前的“临时”修复程序所证明的那样。我希望有人比我聪明（或者至少比我更专注）能解决这个问题。
5 个赞
完全同意，百分之百。我们有一个论坛位于澳大利亚，并将已关闭的主题用作事实上的邮件列表。几乎所有人都位于澳大利亚，并期望会议时间能反映这一点。电子邮件中的 UTC 对许多用户来说完全令人费解。
我们至少能否设置所使用的时区，并允许每个实例选择是否覆盖它。
3 个赞
@j.jaffeux / @hugh / @lindsey 你们觉得怎么样：
它：
- 将默认电子邮件格式更改为 llll（例如：2018 年 5 月 8 日星期二上午 2:00）
从 2018-05-08T00:00:00Z UTC，这在视觉上不那么美观 - 添加了
discourse_local_dates_email_timezone，允许配置
电子邮件中的默认时区 - 改进了站点设置的帮助文本（格式/时区）
因此，在高度本地化的 discourse 的情况下，您可以将其设置为国家的时区，这样电子邮件就不会那么令人困惑。
这不幸有点复杂，将其融入管道并非易事。
5 个赞
无论您如何呈现时间，请务必始终包含所选时区！
2 个赞
抱歉，我不太明白，你能详细解释一下你在这里的意思吗？
在示例文本中，没有时区。我说那将是糟糕的，如果那真的是将要使用的。我强烈建议添加适当的三个或四个字母的时区描述符，或者国家/城市的长格式描述符。现有文本中有“UTC”，这是对其含义的明确指示——新的行为应该至少和它一样好。
即使在“高度本地化的讨论”中，也可能存在邻近时区的用户，可能存在夏令时变化，也可能有用户在旅行并从远处访问。
2 个赞
来自同一个 PR 
discourse_local_dates_email_format:
default: "llll UTC"
这不是我必须坚持的原则，但现在日期很难理解，所以我更愿意让纽约/伦敦/巴黎得到一些稍微不那么令人困惑的东西……但很难想出一个对每个人都适用的格式。
不过，我们可以保持默认的现状。
1 个赞
如果我将 discourse_local_dates_email_timezone 更改为“Europe/Paris”，但未将格式更新为“llll Europe/Paris”，会发生什么？这会导致时间转换为巴黎时间，但后面仍然显示“UTC”吗？
2 个赞
是的，会发生这种情况，设置是相互关联的，你必须同时更改两者。
在我提交的 PR 之前，我们硬编码了“UTC”文本，所以甚至无法配置。
3 个赞
这对我来说似乎容易出错。是否可以自动显示选定的时区，而不是期望管理员手动更新格式？使用 "llll z" 作为 discourse_local_dates_email_format 的默认值是否可行？
5 个赞
Moin，抓得好 
它奏效了，我更新了我的 PR
6 个赞