夏时制更改的木兰CMS DateFieldDefinition问题 [英] Magnolia CMS DateFieldDefinition issue with Daylight saving time change

问题描述

使用

< h3>那是很有趣的地方：

4. 我将计算机的日期更改为 2016年11月2日 >，

   
   

   ---

   
   

   插图

   
   
   
   
   
   
   
   

   解决方案

   由于一些问题，Magnolia 5中的日期/时间实现非常（可能仍然很糟糕）：

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

   我写给Magnolia的关于这些问题的支持票，他们说他们已经在Magnolia CORE 5.4.11中修复了该问题，该票证自5.5.1起可用。我尚未测试这些修复程序，但是除非您使用此修复程序版本，否则我不建议您为您的问题提供一个简单的解决方案，该解决方案是我上面提到的问题的基础。我这样做只是为了记录使用提供的类为您的用例提供正确行为的空间，除非您完全需要他们已经实现的用例。

   
   

   When using Magnolia CMS' DateFieldDefinition class: if my computer's current date is not matching the saved date's Daylight saving time, the saved date's time will be incorrect.

   The relevant class: info.magnolia.ui.form.field.definition.DateFieldDefinition.

   The relevant Vaadin component "Date and Time Input with DateField".

   Another person seemed to have the same problem.

   EDIT: Magnolia CMS appears to have a ticket about this issue already

   ---

   Example:

   In this example, I am running Magnolia CMS locally.

   1. My computer's current date is Oct 17th, 2016

   2. My computer's TimeZone is "Switzerland/Zurich"; hence I am on GMT+2 for the current date (summer time for my time zone)

   3. In Magnolia Admin Panel, I save a date on Nov 3rd, 2016, hence that date is in winter time for my time zone, so GMT+1

   That's where it gets interesting:

   4. I change my computer's date to Nov 2nd, 2016, hence I am on GMT+1 (winter time for my time zone)

   5. In Magnolia Admin Panel I open that date, it shows one-hour less.

   ---

   Illustrations

   解决方案

   The date/time implementation in Magnolia 5 was (and possibly still is) rather bad because of several issues:

   • It failed to distinguish between points in time (e.g. Skype appointment with someone possibly in another time zone) and "concept" times (e.g. a note when to make breakfast - it will always be at 7:00, no matter what time zone, so it's not about a specific point in time but about the concept of 7 o'clock)
   • It saved dates as timestamps although dates are neither timestamps nor time spans. This inaccuracy lead to the next problem:
   • Since dates were treated as timestamps by Magnolia 5 and timestamps were always handled as "points in time" by Magnolia 5, dates were also treated as points in time by Magnolia 5 although this is always wrong. Dates are always just "concepts" (in above sense), e.g. dates of birth. If I'm born on 1st January 1980, then that's my date of birth, and that is so in every time zone. My date of birth is not 31st December 1979 in another timezone, like it would with the "point in time" semantics mentioned earlier.
   • Dates and times were saved as instances of Calendar in JCR, that is a timestamp with a timezone. When transferring data from one Magnolia instance to another (Export, Import, Activation), the actual timestamps were copied as they were, they were not converted to the timezone of the target system. This meant that when the target system finally read the values, it may have seen wrong dates and/or times unless it explicitly converted the values.
   • Magnolia used to use the Browser's time zone for reading dates/times from the user by the Vaadin date/time fields but the server time zone for storing them in JCR. This meant there was always an implicit translation that may or may not have been wanted in the business logic. In many cases wrong values would end up in the repository (e.g. when entering dates of birth), so the later processing based on them had a certain probability of going wrong. In any case it had to be expected that the date/time saved in the repository was not the one the user had entered.

   In a support ticket I wrote to Magnolia about these isuees they said they had fixed it in Magnolia CORE 5.4.11, which will be available since 5.5.1. I haven't tested these fixes yet, but unless you use this fixed version I wouldn't recommend to expect a simple solution for your problem, which comes on top of the problems I mentioned above. I did so just to document how little room there is to get the correct behavior for your use case with provided classes unless you needed exactly the use case they had implemented.

   这篇关于夏时制更改的木兰CMS DateFieldDefinition问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！