[MAGNOLIA-597] Date control constantly adjusting for time zone Created: 15/Nov/05  Updated: 23/Jan/13  Resolved: 26/Jan/06

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 2.1.3
Fix Version/s: 2.1.4, 3.0 Beta 1

Type: Bug Priority: Major
Reporter: Thomas Duffey Assignee: Philipp Bärfuss
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 3d
Time Spent: Not Specified
Original Estimate: 3d
Environment:

Various Linux test environments plus whatever the official Magnolia demo is running on


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   

Date control values are being adjusted by the server in very strange ways. First, when you add a value to a date control and then view it on the page, the date/time shows up as if the value you entered was in GMT and the server adjusts for the local time zone. Second, when you go back in to edit the value the same thing happens. This is easily reproduced on the official demo by creating a page with the developer showroom template and then playing around with a date paragraph.



 Comments   
Comment by Thomas Duffey [ 15/Nov/05 ]

Line 562 of info.magnolia.cms.gui.control.Save sets the input timezone to GMT:

date.setTimeZone(TimeZone.getTimeZone("GMT"));

There is a "todo" comment around this line about dealing with time zones some day.

Comment by Thomas Duffey [ 15/Nov/05 ]

Removing line 562 from the aforementioned comment seems to be helping. The date remains consistent both in the paragraph output and the edit control.

However, I see a need for more flexible time zone settings, especially when the server's time zone is not the same as the user's time zone. I recommend adding a time zone attribute to users to specify that user's local time zone, and then making date controls smart enough to convert input timestamps from the user's time zone to the server's time zone.

Another approach worth considering is to store dates in GMT, but then you have to figure out why the values are shifting when output. I suspect it's because the output date formatter needs to know the time zone of the input date. I actually think this is the best solution, but it's also a little more work than just throwing out line 562.

Comment by Philipp Bracher [ 21/Nov/05 ]

date.setTimeZone(TimeZone.getTimeZone("GMT"));

This was set do avoid the time shift during saving. This was leading to proplems during the search mechanism. I will try to fix the bug.

Thanks!

Comment by Philipp Bracher [ 26/Jan/06 ]

The date is stored with timezone UTC (no timeshift). If the time would be stored in the locale timezone (1.1.2006) for example with a shift of -2 hours it would store
31.1.2005T22:00:00.000. If you use the search term date >=2006.01.01 it would not find this entry.

I have changed this some time ago.

Therefore we must print out the times and dates using the UTC timezone.

I have fixed the date control and the c:out tag

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