Discourse 日历今天收到了重大更新 
。更新的核心是将 fullcalendar 4 迁移到fullcalendar 6，这将为我们带来更新的 UI：
我们还借此机会进行了以下更改：
-
即将举行的活动页面的干净 URL，例如：
/upcoming-events/day/2025/8/2 -
点击事件时显示事件预览
-
性能得到了极大提升，现在应该可以处理大量事件了。
-
我们现在依赖 fullcalendar 提供的 css 变量，这应该能让日历开箱即用，与您的主题兼容。
29 个赞
干得漂亮，非常感谢 
2 个赞
有个小问题，我们能否为移动部分默认使用年份列表？
如果不行，那还是非常棒！！
感谢您的工作！这些网址是否同时支持美国/欧洲日期格式系统？如果同一天有多个活动，该怎么办？
抱歉，我们目前仅支持一种网址格式。
这并不妨碍您查看当天/当月/当年的所有活动。如果您想直接链接到某个活动，请链接到该活动的帖子。
2 个赞
确实，可以直接分享事件的链接，提供多种URL格式并非易事。我们非常感谢您为fullcalendar 6带来的这个包含新功能的更新！
1 个赞
升级后，我注意到某些事件的主题发帖时间（正确）与日历显示时间（早一小时）之间存在一小时的差异，但并非所有事件都如此。
这要么在我们当地时区切换到夏令时后得到解决，要么在夏令时开始后导致其他一些事件（反向）出现问题。但并非所有事件都受到影响。这是一个已知问题吗？是否有计划中的修复程序？
太棒了！这确实将日历提升到了一个新的水平。
我注意到在（默认的）月视图中，事件标题的文本不会换行。这是故意的吗？
桌面日历
在桌面上，我们希望能看到月视图中完整的标题（？也许是悬停时），因为这些标题通常包含有用的信息。当然，这也会意味着事件可能会变得贪婪并占用更多空间。
移动日历
另外，在移动设备上，很少能看到比时间更多的信息。我想这不那么重要，因为点击它们很容易看到更多信息。
日程视图？
最后，拥有一个日程视图将非常有帮助，这是表示事件的常见方式。通过日历是否可以实现？
我知道使用 Right Sidebar Blocks 可以实现这一点，但这处于不同的上下文中。
2 个赞
是的，我今天会修复这个问题，我正在等待一个确定的重现步骤，谢谢。
3 个赞
应该已通过以下方式修复：FIX: removes support for include_expired param (#34582) · discourse/discourse@249ae00 · GitHub
1 个赞
我有一个小建议 
与其去到今天的日期，不如直接去到下一个事件的日期？
这只是一个想法！ 
我认为今天应该会开放。如果您需要将用户链接到特定日期，现在可以创建您想要的链接：/upcoming-events/day/2025/9/2
谢谢！
是否可以遵循 ISO 日期格式？例如 YYYY/MM/DD（月份和日期为两位数）？
3 个赞
我主要遵循谷歌的做法：
啊，既然他们可以打破标准并给别人制造更多麻烦，为什么还要遵守标准呢？
2 个赞
我不明白为什么 /day/2025/09/01 比 /day/2025/9/1 好这么多。
我敢说，添加零会更糟，因为它在地址栏中占用了更多空间。
它并没有更好。只是更标准化，并且与 Discourse 其他部分编码日期的方式一致。
相反，目前实施的方式与 Discourse URL 一致（需要开放式编号）。
所以，这是一个哲学决定。与 URL 的内部一致性，或与日期的内部/外部一致性。两者各有利弊。我更喜欢目前的实施方式。
如果我开始写那个日期，格式将是月/日。因为这是几乎所有地方的标准——除了来自美国的连接，他们会去掉前导零，并以大写字母开头 
。或者来自计算空格的编码人员，因为即使是美国人也能读懂并使用月/日。
所以，这是肌肉记忆的问题，也是一个事实，即世界上大部分地区都习惯使用 ISO 格式，并且很难记住哪个软件和平台使用哪种格式。这是那些总有人会输的问题之一——问题是哪个群体最大。
2 个赞
哈！抱歉，我不想纠结于细节。纯数字是按数值排序的，前导零可以使月份按正确顺序显示。
3 个赞
我仍然看到在当地时间更改为夏令时之前和之后的重复事件的异常行为。我们使用的是托管计划，所以这只是一个等待修复推送的问题吗？