2

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

Saved date when machine date is Oct 17th, 2016

That's where it gets interesting:

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

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

Saved date when machine date is Nov 2rd 2016

Illustrations

Switzerland/Zurich - time changes & time zones

Switzerland/Zurich - November winter time

Switzerland/Zurich - October winter time

Same issue described in Magnolia Doc's comments

Community
  • 1
  • 1
Adriano
  • 19,463
  • 19
  • 103
  • 140
  • What's the timezone in your user profile? Is it the browser timezone? Does a change to a custom timezone fix the issue? – Roman Oct 18 '16 at 07:06
  • I EDITED the question for you: I pointed out the fact that I was running Magnolia CMS locally, & updated screenshots (pointing to my machine's time). What these screenshots mean: it's not because I book now (in summer time) an event that will happen in winter time, that when we are in winter time I want that event to change time. Does it makes sense? This is regardless of the TimeZone of the machine Magnolia is running on, regardless of Magnolia's setting TimeZone, regardless of the browser's TimeZone, & regardless of the client's computer's TimeZone. – Adriano Oct 18 '16 at 15:27
  • 1
    @AdrienBe - Looks similar to this issue: https://jira.magnolia-cms.com/browse/MGNLUI-4014 – MattDiMu Oct 18 '16 at 15:28

1 Answers1

4

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.

TXN
  • 101
  • 6