nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

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.

Find more posts tagged with

Alfresco Content Services

Comments

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.

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.
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.
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).

sp2

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)

AlfrescoZZZ

did you find a solution for this ?