serious date/time problems in Alfresco

[roli8200]

I recognized some serious date/time problems in Alfresco.

1: Alfresco completely ignores the local timezone. Even when set -Duser.timezone=Europe/Zurich in JAVA_OPTS in catalina.sh, it sets dates always as Zulu (UTC)

2: The informations in: Date and time format | Alfresco Documentation  are partially wrong.

These dates are only applicable for fields like Creation Date or Last Modified Date

3: When I make a custom aspekct with a property of type date, it always sets the wrong date from date picker.

I set (iso) 2017-05-10, the CMIS query for that date field shows me 2017-05-09T22:00.00.000Z (see also #2,#1)

which is completely wrong and a huge problem, specially because this date should be furter processed by downstream processes via CMIS.

Can someone from alfresco please take care of all that problems and fix the date/time processing routines in Alfresco?

I know Oracle/Sun made serious bugs the (in the meantime) several date/time apis in Java, specially the last one in Java 8 

is a declaration of bankruptcy by Oracle.

Maybe some diffrent java apis are in use by diffrent components which are incompatible. 

[mehe]

Hi there,

To your first point, local timezone vs. utc. I think it's the expected behaviour to work with utc, because alfresco is also supposed to work for organizations that collaborate via multiple timezones. For that, you would have to depend on a shared time base - which normally is UTC. Linux Servers do that for some time.

to 2: I think the ISO format is the long format as described in the docs. Z is sometimes omitted when referring to utc, but that should not be problem - but in this point I'm lacking a bit of experience because the last client GUIs I created or worked with, where angularjs (JavaScript based) and handled my date problems well.

to 3: this seems to be the effect of converting the time picker datetime, which would set the time to 00:00:00. Your time is 2 hours off because of daylight saving. I usually patch/set date delivering components to use 12:00:00 (or NOW) which isn't correct either but saves me from getting the wrong day.

The most people of the community are not related to alfresco and won't be able to fix your date related issues, sorry :-(

Regards,

Martin

[afaust]

I mostly have to agree with Martin here. I actually don't see a technical bug at all at play here, just subjective assumptions about how dates should be treated that don't align with the reality.

1. Any timezone set via -D is irrelevant when storing a specific ISO8601 date submitted from a client. Timezones set that way are used primarily for formatting dates for text output and when you have a log output anywhere that includes a Java date as data payload you will see that date output in the timezone you have specified. Alfresco should never "manipulate" an exact date provided by a client based on the server timezone. And Martin is right that UTC simply is the standard for storing date values.
2. The documentation is only slightly wrong in that Z is usually used instead of +00:00 - but both are valid and interchangible according to ISO8601. Also, the use of ISO8601 for dates in JSON extends to all properties of type d:date and d:datetime, not just the created/modified date.
3. CMIS only understands datetime - not simple date values. For that reason, any partial ISO8601 date (e.g. 2017-05-24) that you provide will always be treated as a datetime value and stored using its UTC value. If a client or downstream processes need to process that value in some way then it is the responsibility of these components to use the proper timezone for evaluation. Alfresco as a storage system should not force values in a specific local timezone / form that would lead to loss of information / universal access.

[ivanovpavel1983]

We have the same problem with REST API v1:

But openDate is 2017-12-27!!!

The same with BirthDate:

Real birthdate is 01.01.1988!!

The datatype is date:

This is inadequate behaviour of Alfresco Rest API (get nodes, search api) ((

Does anyone known how to fix this case in Aikau, for example?

How can I add 3/4 hour before renderes this date in the AlfList in Aikau, for example with ALF_DOCLIST_RELOAD_DATA  topic?

And now, for correct search I should do this, before call Rest API:

[afaust]

The ReST API simply returns the date in a standardised timezone which is UTC. So if you used the ReST API to set a date in +03:00 timezone, then this response is correct. All dates are always stored with the time portion, typically with 00:00 based on the timezone of the end user.

The inadequate behaviour is in the date rendering - unfortunately, none of the Aikau rendering widgets by default translate a date value into the local timezone of the end user. This is something that would require a custom extension e.g. of the alfresco/renderers/Property widget, which I have done for a few customers at my old employer.

According to the API Explorer for the Alfresco v1 REST API, the search API provides a parameter for timezone within the request body (locallization/timezone). Did you try this? This should be used to tell SOLR to evaluate any query dates that do not include an explicit timezone in a default timezone instead of Zulu (Z / UTC).

[ivanovpavel1983]

Hello, I tried to use localization and timezone parameters  in the request to search service of REST API v1.

When I added timezone in the request, there was an error like 'unknown parameter'...

When I added localization(i used GMT+1, GMT-12, GMT+12 and so on), there were no changes in the response ((.

Tomorrow I will send the examples of my requests.

[afaust]

The timezone specified must match the format(s) recognised by the Java ZoneId + TimeZone classes. I used "Europe/Berlin", "GMT+01:00" as well as "GMT+1", and it worked perfectly. The full body to my request was:

{"query": { "language":"afts", "userQuery":"Test", "query": "Test"},"localization":{"timezone":"GMT+1"}}

Note: Setting the timezone only affects the SOLR date math. Specifically, the setting will be used to set the "TZ" parameter in SOLR queries, documented here. Date parsing in queries still uses UTC, contrary to what I believed in my previous statement. But with regards to birthday / date requirements, you should be able to do queries like

{"query": { "language":"afts", "userQuery":"otp:birthDate:[\"1988-01-01T12:00/DAY\" TO \"1988-01-01T12:00/DAY+1DAY\"]", "query": "otp:birthDate:[\"1988-01-01T12:00/DAY\" TO \"1988-01-01T12:00/DAY+1DAY\"]"},"localization":{"timezone":"GMT+1"}}

and properly find only those with their birthday on precisely 1988-01-01 in the specified timezone (even though the value will still be shown in UTC and thus with an offset). 12:00 is chosen as the time value because most timezones are within +12/-12 from UTC - only New Zealand Daylight Time and some Pacific islands use differences greather than 12 (up to 14 for Kiribati).

[ivanovpavel1983]

Axel, hello. Thanks for help. We are using Solr6 & ACS 5.2.2

I tried this request (with different GMT +/- values and with UTC )

and response is empty:

As workaround I send date - 1 day:

And response is сorrect

In Aikau, at this moment,  I do this: ((

[sanjaybandhniya]

I have also same question.

[deli]

And what about search documents based on custom date property in Alfresco Share?

I have documents of custom type with d:date type property.

I set document date property for example to 31/3/2021. When I check properties in Share the value is as was set - 31/3/2021. When I check it over CMIS value 30/3/2021 22:00:00 is stored (as was described here - it is converted to UTC).

Share AdvancedSearch is configured to search this date property (using template datarange.ftl). I want to search documents from 31/3/2021. But document  with date 31/3/2021 is not in search results. To find it the date value to search from has to be 30/3/2021. What is wrong? Search in Share doesn't make time "conversions"? Is it possible to configure Share to search date property as expected? If so, how?

Thanks

Regards

Petr

(Alfresco Share v6.1.0-RC3, Alfresco Community v6.1.2)