【问题标题】：Magnolia CMS DateFieldDefinition issue with Daylight saving time change夏令时更改的 Magnolia CMS DateFieldDefinition 问题
【发布时间】：2025-11-21 20:30:01
【问题描述】：

使用Magnolia CMS' DateFieldDefinition class时：如果我的计算机当前日期与保存日期的夏令时不匹配，则保存日期的时间将不正确。

Another person seemed to have the same problem.

编辑：Magnolia CMS appears to have a ticket about this issue already

示例：

在本例中，我在本地运行 Magnolia CMS。

我计算机的当前日期是 2016 年 10 月 17 日
我电脑的时区是“瑞士/苏黎世”；因此我在GMT+2 for the current date (summer time for my time zone)
在 Magnolia 管理面板中，我将日期保存在 2016 年 11 月 3 日，hence that date is in winter time for my time zone, so GMT+1

这就是有趣的地方：

我将计算机的日期更改为 2016 年 11 月 2 日，hence I am on GMT+1 (winter time for my time zone)
在 Magnolia 管理面板中，我打开了那个日期，它显示少了一小时。

插图

【问题讨论】：

您的用户资料中的时区是什么？是浏览器时区吗？更改自定义时区能否解决问题？
我为您编辑了问题：我指出了我在本地运行 Magnolia CMS 的事实，并更新了屏幕截图（指向我机器的时间）。这些屏幕截图的含义：并不是因为我现在（在夏季）预订了将在冬季发生的活动，所以当我们在冬季时，我希望该活动改变时间。这有意义吗？这与运行 Magnolia 的机器的 TimeZone 无关，与 Magnolia 的 TimeZone 设置无关，与浏览器的 TimeZone 无关，也与客户端计算机的 TimeZone 无关。
@AdrienBe - 看起来类似于这个问题：jira.magnolia-cms.com/browse/MGNLUI-4014

标签： java datetime magnolia

【解决方案1】：

由于几个问题，Magnolia 5 中的日期/时间实现（并且可能仍然是）相当糟糕：

它无法区分时间点（例如与可能在另一个时区的某人的 Skype 约会）和“概念”时间（例如，何时做早餐的注释 - 无论什么时间，它总是在 7:00时区，所以它不是关于特定时间点，而是关于 7 点钟的概念）
它将日期保存为时间戳，尽管日期既不是时间戳也不是时间跨度。这种不准确导致了下一个问题：
由于 Magnolia 5 将日期视为时间戳，并且 Magnolia 5 始终将时间戳视为“时间点”，因此 Magnolia 5 也将日期视为时间点，尽管这总是错误的。日期总是只是“概念”（在上述意义上），例如出生日期。如果我出生于 1980 年 1 月 1 日，那么这就是我的出生日期，在每个时区都是如此。我的出生日期不是另一个时区的 1979 年 12 月 31 日，就像前面提到的“时间点”语义一样。
日期和时间在 JCR 中保存为日历实例，即带有时区的时间戳。将数据从一个 Magnolia 实例传输到另一个实例（导出、导入、激活）时，实际时间戳按原样复制，它们没有转换为目标系统的时区。这意味着当目标系统最终读取这些值时，它可能会看到错误的日期和/或时间，除非它明确地转换了这些值。
Magnolia 过去使用浏览器的时区通过 Vaadin 日期/时间字段从用户读取日期/时间，但服务器时区用于将它们存储在 JCR 中。这意味着在业务逻辑中总是存在可能需要也可能不需要的隐式转换。在许多情况下，错误的值最终会出现在存储库中（例如，输入出生日期时），因此基于它们的后续处理有一定的出错概率。在任何情况下，都必须预料到存储库中保存的日期/时间不是用户输入的日期/时间。

在我写给 Magnolia 的关于这些问题的支持票中，他们说他们已在 Magnolia CORE 5.4.11 中修复了该问题，该问题将从 5.5.1 开始提供。我还没有测试过这些修复，但除非你使用这个修复版本，否则我不建议你期待一个简单的解决方案来解决你的问题，这是我上面提到的问题之上的。我这样做只是为了记录使用提供的类为您的用例获得正确行为的空间有多大，除非您完全需要他们已经实现的用例。

【讨论】：