[MGNLUI-2694] Dates and times should be displayed in a configured timezone to not confuse user Created: 19/Feb/14  Updated: 22/Feb/17  Resolved: 28/May/16

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: 5.4.4
Fix Version/s: 5.4.7

Type: Bug Priority: Major
Reporter: Daniel Lipp Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File Screen Shot 2014-02-19 at 13.52.01.jpg     JPEG File Screen Shot 2014-02-19 at 13.58.05.jpg     JPEG File Screen Shot 2014-02-19 at 13.58.24.jpg    
Issue Links:
Relates
relates to MGNLUI-2475 DateField: timezone out of synch betw... Closed
relates to MGNLUI-3621 Make date picker time zone configurable Closed
relates to MGNLUI-4014 Investigate into corner cases: Wrong ... Closed
dependency
depends upon MAGNOLIA-6660 Add timezone property to User class Closed
relation
is related to MGNLUI-2695 User can configure his timezone Closed
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
Date of First Response:
Sprint: Kromeriz 46
Story Points: 5

 Description   

Steps to reproduce:

  • setup a server having a different time zone as your client
  • create an event
  • the date and time you can select in the date/time chooser are using the client timezone (as you would expect)
  • once you safe, the date/time will be rendered without considering the client timezone and hence show an unexpected value

(storage in JCR is fine)

A workaround is to add the time diff in hrs between the server and the client timezone to the date/time you're entering.



 Comments   
Comment by Mikaël Geljić [ 19/Feb/14 ]

Vaadin DateFieldFactory does assign the current client timezone to the field before setting the value, hence why 8:00 AM is correctly converted into 14:00.
Now regarding date/time formatting, formats are hard-coded in DateFieldDefinition, they should use default locale formatting if not specified instead.
Then same goes probably for the stkEvent, it shouldn't render AM/PM format when browsed from e.g. Switzerland.

Comment by Daniel Lipp [ 19/Feb/14 ]

Greg and me came to the conclusion, that for events it would correct to save the date/time in the timezone of the client creating it. In the context of events we don't want to calculate proper date/time from the client and server timezone when rendering the event but simply show the date/time as entered by the other. E.g. if there's an event today at 2pm at Boston we don't want to display a completely other time just because a visitor might surf the website from somewhere in China.

Comment by Roman Kovařík [ 02/May/16 ]

We can already set a timezone on the date field, see:
https://dev.vaadin.com/ticket/6066
https://dev.vaadin.com/ticket/6691
https://dev.vaadin.com/ticket/7450
That's completely enough to show the times in different timezones.
But it's more tricky when it comes to choosing a date from a browser:

  1. The date is created in com.vaadin.client.ui.VPopupCalendar#openCalendarPanel
  2. new Date() always use the browser locale (no matter what we configure on the date field)
  3. We currently workaround it in info.magnolia.ui.form.field.factory.DateFieldFactory#setTimeZone where we are counting the offset.
  4. This is still fine until we use the timezone (use 'z' or 'Z') in the date format:
  • the showed timezone is always the browser timezone, but that not true because we recount it in the date field factory.
  • The easiest solution is to forbid showing the timezone in the editable date fields (since the displayed timezone would be wrong anyway)...we can still show it readonly date fields.
  • Complex solution would be to extend the client side to include the timezone information (in currently works only with days, hours...)
Comment by Mikaël Geljić [ 03/May/16 ]

First two tickets are old and released, I understand 7450 is still open, but it's only an enhancement for an application-wide (or component-tree-wide) setting.
Isn't DateField#setTimeZone, as done at DateFieldFactory:107 doing the trick? Maybe worth explaining in more details which part you're trying to address too

Comment by Roman Kovařík [ 03/May/16 ]

^^ Updated the commend above

Comment by Mikaël Geljić [ 03/May/16 ]

Right, the client-side Vaadin widget and connector haven't got any notion of time zone (on its own it's not necessarily a bad thing).
But right, 'z' sticks to the browser offset, regardless of the DateField's selected time zone. Field value on the other hand will be appropriately converted by Vaadin, to add to the confusion.

Anyway, we cannot display offsets for user input: offsets are sensitive to the chosen date (e.g. depending on DST you might want to format as UTC+1 or UTC+2).

  • same for read-only fields. We don't have to take any measure to forbid it, in my opinion, besides *not* advising it.
  • We could add a static label next to the field to remind of the time-zone, when its offset is different from the detected one.
  • Is it also an option to configure a fixed timeZone (not offset) on the DateFieldDefinition, so that all authors know what to refer to?
  • ... until we make this a Vaadin CustomField with a layout and a time zone picker, kind of like this: https://gist.github.com/mkgl/c6178761bfb9000062f8910bdaf51804
Comment by Mikaël Geljić [ 04/May/16 ]

linking to ticket where timezone awareness in date-field was implemented;
linking as well to a recent ticket requesting a timezone setting on the date-field definition. I guess it would be a quick win too.

Comment by Marvin Kerkhoff [ 19/Oct/16 ]

We / You have a huge bug in Magnolias datefields. If you save a date in the winter period with the time set before 30th of October 2016 it will save all dates -1 hour in the database.
This means that every datefield without a time is set automaticly to 00:00 but in case of the wintertime it's saved for the time 23:00 from the day before.
The datefield is showing the correct date but in the database it is saved one day before. That is messing up a lot of things. Please have a look to fix this.

More Informations and an example here:
http://stackoverflow.com/questions/40090952/magnolia-cms-datefielddefinition-issue-with-daylight-saving-time-change

Comment by Pierre Sandrin [ 02/Feb/17 ]

Hello Marvin
I confirm the Summer/Wintertime bug (Magnolia 5.5). Could you resolve or find a workaround for it? Did you already open a jira bug for this issue? It makes DateField unusable...

Comment by Marvin Kerkhoff [ 02/Feb/17 ]

Hi Pierre,

yes there are several bugs reported in JIRA. https://jira.magnolia-cms.com/browse/MGNLUI-4014 This is the main ticket. We have just updated to 5.5.1 version which should fix the bug. But we are not at the point where i can definetly say that it is fixed. But you can give it a try.

Thx
Marvin

Comment by Pierre Sandrin [ 02/Feb/17 ]

Thanks, I will update to 5.5.1 then

EDIT: The bug is fixed

Generated at Mon Feb 12 08:59:13 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.