This is a complex problem and needs severe PM attention. It cannot simply be fixed since a fix could break existing behavior. It should be forwarded to the Repository practice after PM review.
Alfresco knows a pure date value ("d:date") in its data model. Values of this type are read from and written to the database aligned to the server startup timezone. This causes date values to suddenly change.
You need two different machines: one for client that runs the share UI in a browser and a second one that runs the repo+share server(s)
- Configure the repo with a content type that contains a property of type d:date
- Set the timezone of the client to Berlin (UTC+1)
- Set the timezone of the server to Brisbane (UTC+10)
- Start the repo and share
- On the client, add a document to the repo with share, set your content type and assign "2015-03-10" to your date value
- Stop the repo server (you can keep share running)
- Change the timezone of the server to Hawaii (UTC+10)
- Restart the server
- Do not change the timezone of the client
- Refresh the share page in the browser on your client
The test date still shows 2015-03-10
The date suddenly changes to 2015-03-09
I have not tested if this is also triggered by DST. It is possible that if a server is first started in the winter and then restarted in the summer (or vice versa), that all d:date values jump by 1 day.
We did not touch the timezone of the client. We just restarted the server in a different timezone. So this is not a conversion / display problem in share!
Effect on the system:
You can find dozens of tickets in JIRA complaining about problems with dates, for example:
ACE-250 - Task due date timezone is ignored when email is rendered
ALF-15934 - Recurring events with times zones appear on the wrong date within Share
SHA-128 - My Calendar dashlet displays incorrect event time after DST change
MNT-13432 - Emails: Inconsistent display of Sent Date in Share for emails archived with Alfresco Outlook Client
...and many other more. It is very likely that these problems are all raised against share but are in fact caused by this date problem in the repository.
The root of the problem:
The values of properties of type d:date are represented in our java API as java.util.Date. But a java.util.Date is not suitable for a pure date. Instead, it identifies one point on the timeline and is agnostic to the representation of this point on the timeline. A pure date instead should not be subject to any timezone or DST conversions. If a user sets the "date of birth" to "15 Mar 2005" in the summer in Brisbane, than the "date of birth" should have the same value for users in Hawaii or in the winter.
Instead of a java.util.Date, a pure date should be represented by a java.sql.Date.
Possible solution / workaround
It is possible to simulate a java.sql.Date with a java.util.Date by convention. We could define to store a pure d:date value with the time zeroed out in UTC. But this still requires that everybody dealing with d:date values is aware of this convention and treats the values properly. If a user accidentally applies TZ conversion to this value, we will again end up with a different date.
It is even possible to immunize these date values against accidentally TZ conversion. We could store date values aligned to the International Date Line (IDL). When storing a date with the time zeroed out in UTC-12 (i.e. T12:00:00+00:00 in UTC), then an accidentally applied TZ conversion will keep the date part intact for most of the timezones. But it will still fail for the timezones UTC+12, UTC+13 and UTC+14.
Problems when trying to fix this:
We have multiple modules in the Repository and on top of the repository that currently interact with these values (e.g. Share, Metadata Extractor, AOS, CMIS, ...). It is likely that these modules already apply some workaround code that will break after fixing this issue.
We can use version 5.1 to change the java class of d:date values from java.util.Date to either java.sql.Date or the new Java8 java.time.LocalDate.