[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) b) set a date and time which is aware of the 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. |