[MAGNOLIA-3550] Date form control handles timezones incorrectly Created: 11/Feb/11  Updated: 04/Aug/15  Resolved: 04/Aug/15

Status: Closed
Project: Magnolia
Component/s: admininterface
Affects Version/s: 4.2.2
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Toby O'Rourke Assignee: Unassigned
Resolution: Outdated Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

tested on ubuntu/jboss - presume it occurs on all environments.


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:

 Description   

When the author is running in UTC but the editor's local machine is running in a different timezone (I chose GST which is UTC+4 for my testing) the Date control will use the time from the local machine, but this will be persisted as UTC.

This means I might choose a date/time of 12:00 11-02-2011 which will be persisted as 11-02-2011T12:00:00Z. When I next view the content on the local machine I will see the date/time is 12:00 10-02-2011, as I intended. However, because this is now UTC and not GST it is actually 4 hours later than I intended. If I am using the Date control to set startDate in order to delay the activation of content, that content will be activated 4 hours after the intended activation time.



 Comments   
Comment by Philipp Bärfuss [ 15/Feb/11 ]

This is actually a discussion we had several time and it depends on what you want to do.

a) set a fix date and time (for content)
This is normally what you want to happen if you edit content. The value should not depend on the authors timezone.

b) set a date and time which is aware of the timezone
This is used if things should be dynamic, a user is able to set at publication date which differs from the server's timezone

The default case supported in the magnolia dialogs is a) not b)

You can change this by defining a saveHandler nodedata in your dialog denoting a class having a custom implementation of SaveHandlerImpl.processDate(Content, String, int, int, int, String[])

Alternatively you can do the same thing on the control/field level. The interface to implement is then FieldSaveHandler.

For future version this should be configurable on the control level (allow timezone aware dates).

Comment by Toby O'Rourke [ 17/Feb/11 ]

Hi,

a) is indeed what I want to do, but it is broken. The date component picks up the local time of the machine the browser is running on, say 18:00 GST (14:00 UTC), which is then saved as 18:00 UTC (22:00 GST). It still reports it as 18:00 to the user (with no obvious timezone) so they will experience the content activating 4 hours later than expected.

If the date control displayed UTC at all times, or was able to convert from UTC to local time there would be no issue.

Comment by Philipp Bärfuss [ 08/Mar/11 ]

I am re-opening. We have to verify that the default scenario works as expected.

Comment by Michael Mühlebach [ 04/Aug/15 ]

We're closing this issue as outdated as it was reported for 4.4.x or earlier versions which are no longer supported. Don't hesitate to reopen or create a new ticket in case this is still relevant and you'll experience it on 4.5.x or later versions.

Generated at Mon Feb 12 03:47:32 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.