[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: |
|
||||||||||||||||||||||||||||||||||||
| 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:
Nr2:
|
| 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. 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. 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). Regarding @Richard comments: |
| 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 |
| 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 |
| 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. 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 |