[MGNLUI-4014] Investigate into corner cases: Wrong timezone calculation in DateFieldFactory Created: 12/Sep/16  Updated: 07/Jul/17  Resolved: 11/Jan/17

Status: Closed
Project: Magnolia UI
Component/s: forms
Affects Version/s: 5.4.9
Fix Version/s: 5.4.11, 5.5.1

Type: Bug Priority: Critical
Reporter: Christian Ringele Assignee: Mikaël Geljić
Resolution: Fixed Votes: 8
Labels: regression
Remaining Estimate: 1.5d
Time Spent: 2.5d
Original Estimate: 4d

Issue Links:
Cloners
is cloned by MGNLUI-4007 Wrong timezone calculation in DateFie... Closed
Relates
relates to MGNLUI-2694 Dates and times should be displayed i... Closed
relates to MGNLUI-2695 User can configure his timezone Closed
causality
duplicate
is duplicated by MGNLUI-4061 info.magnolia.ui.form.field.definitio... Closed
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Release notes required:
Yes
Date of First Response:
Sprint: Saigon 75, Saigon 77, Saigon 78
Story Points: 8

 Description   

We should investigate into time zone corner cases as switching from winter to summer time and CET vs CUT time calculations:

From the support ticket:

Nr1:

if one is entering a date for the winter time in a date (time) control, the time is stored incorrect (-1 hour) in jcr.
for example:
date '2016-10-30 12:00' will be saved as '2016-10-30T11:00:00.000+01:00'
another example:
entering date (without time) '2016-10-31' is stored as '2016-10-30T23:00:00.000+01:00'

the problem is when displaying the previously set date using freemarker some_date?string('dd.MM.yyyy'):
the output is '30.10.2016' instead of '31.10.2016'.
this change apparently caused by 5.4.7, prior to this version it was printed correctly.

you can reproduce it using the travel demo:

edit a tour in the tours app
set a date for wintertime 2016-10-31 & save
edit /tours/templates/components/tourDetail.ftl to display the tour date using freemarker $

Unknown macro: {tour.date?string('dd.MM.yyyy')}

edit the TourDetailModel as well, currently it's not returning the date
the output will be '30.10.2016' (-1 hour & -1 day)

Nr2:

Yes it's right that the date will be strored in iso time format with offset but it's not correct, if I'm entering time 12:00 CET in the dialog and in jcr the date is stored 11:00 CET. Although server and browser uses same timezone.
If the browser uses a timezone with daylight saving time the magnolia timezone handling is broken.

And then it's dependent to summer and winter time which date/time I'll see in the date field of an dialog.
Example:
Today (in summer time) I'm entering a date in winter time ('2016-10-31') and then I will open this entry in the same dialog on the 31th of october the date in the date field will switch to '2016-10-30'.
It cannot be right.

IMHO the problem is magnolia only uses offsets and ignores the timezone.
Browser and Server using CET. The stored date is winter time (offset +1) and the browser uses summer time (offset +2). There is the difference of one hour. But what happens if I open the date in winter time? Browser offset +1 and stored date offset +1. Now there is no difference and that's why I see different times in date fields.



 Comments   
Comment by Richard Unger [ 12/Sep/16 ]

I think this issue should be handled with high priority. Anyone using Magnolia 5.4.8+ in europe (or any other region of the world which uses summer-winter time, which is most of the developed world...) is going to have this problem.

The problem is with info.magnolia.ui.form.field.factory.DateFieldFactory, the change in line 124.
To create a SimpleTimeZone here is simply incorrect whenever the actual timezone uses summer time.

In the end, if the user does not have a timezone set, then it is a much better guess to do it the way it was before (eg offset the server timezone with the user's offset information) than to use the SimpleTimezone.
This is because the non-Summertime Scenarios are less likely to occur (most of the western world uses summertime, and most websites will be somewhat local to the areas they serve).

A real solution to the problem cannot be implemented without actually knowing the user's timezone information. So until GWT/Vaadin/Magnolia somehow get the real timezone information from the browser, the most compatible and friendly solution would be to make sure this is configurable for the people who need the change, and not to change the existing behaviour for everyone else.

Comment by AdrienBe [ 18/Oct/16 ]

Hi all, joining the fun here as winter time is starting in...10 days! Let's keep focus & not start moaning about this.

I created a details description of the problem on StackOverflow: http://stackoverflow.com/questions/40090952/magnolia-cms-datefielddefinition-issue-with-daylight-saving-time-change.

Wouldn't be simpler to add a "TimeZone" field to the Date Field properties (https://documentation.magnolia-cms.com/display/DOCS/Date+field).
This way the TimeZone is explicitly set in the config tree (add a "parameters" content that has a "timeZone" property).
Maybe I'm wrong, if not, that'd be an easy win.

Regarding @Richard comments:
"A real solution to the problem cannot be implemented without actually knowing the user's timezone information."
Shouldn't that do the job?

Comment by Matthias Müller [ 19/Oct/16 ]

Using geolocation is probably not the way to go, as it is inaccurate and would cause annoying "website wants to use your location"-popups.

JavaScripts new Date(<string>).getTimezoneOffset() should provide enough information, though, to calculate the different offsets of the chosen/current date in the picker. Unfortunately getting the actual timezone, is much more difficult in JS. Even the popular momentjs lib only guesses the timezone by evaluating different dates throughout the whole year: http://momentjs.com/timezone/docs/#/using-timezones/guessing-user-timezone/

As this issue results in erroneous content, this issue should be addressed asap.

Comment by Marvin Kerkhoff [ 20/Oct/16 ]

+1 It's a huge bug. Please fix it asap.

Comment by Michiel Meeuwissen [ 31/Oct/16 ]

I can add that this bug effectively caused us problems. See MGNLUI-4061

Comment by Marvin Kerkhoff [ 09/Jan/17 ]

Realy 5.5.2? This is unacceptable for me. This is the second shift to another magnolia version. I guess you don't understand which impact this bug has on a database with hundreds of datefields. This means the Datefield is unusable for 5 magnolia versions now? The only way back is to use an older version of magnolia or use a textfield instead of a datefield. NICE

Comment by Mikaël Geljić [ 09/Jan/17 ]

Hi marvink2,

Let me first clarify the invisible progress on that one, behind the scenes. As much painful as this issue is technically, we also have been conducting further UX research as to how to convey the time-zone information along with date input; I was planning to address some improvements here along the way, but this is the part which is likely to slip into the next iteration.

Meanwhile, I'm still pushing hard to provide a minimal fix, since 5.5.2 will indeed get closer to the fire again, and we want to give people enough time to upgrade upfront. On the other hand, it's a tough call, as 5.5.1 already contains a high number of valuable bug fixes and improvements, so we must still deliver it in timely manner.

For the story, rolling back 1-to-1 to the state prior to 5.4.7 is not an option, as it entails other problems when system and user are in time-zones with different DST policies, and in the current UI state may even display contradictory time-zone information (e.g. CET with arbitrary detected offset).

Cheers // stay tuned

Comment by Marvin Kerkhoff [ 11/Jan/17 ]

Hi Mikael,

for me this is still unacceptable. We need another workaround here, i cant' tell all our customers and more then 200 Authors that they can't use datefields anymore. Do you have any idea that helps?

Thanks
Marvin

Comment by Mikaël Geljić [ 11/Jan/17 ]

I hereby confirm this DST issue will finally be fixed in 5.5.1.

The SimpleTimeZone which was forked off user's current UTC offset, without any DST policy, is now gone. In fact the overall unreliable offset detection is gone.
Time zone now resolves either to users' preferred time zone (never suffered this issue) or to system's default. Nothing else.

marvink2, were the issue a major blocker for authors, you can have them configure their preferred time zone in their user profile. Alternatively, dateField's factoryClass can be reconfigured.

Thanks all for your patience and contribution on that one

Generated at Mon Feb 12 09:12:24 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.