cancel
Showing results for 
Search instead for 
Did you mean: 

Alfresco 4.0 Date handling

d_evil
Champ in-the-making
Champ in-the-making
Since 4.0 the new Alfresco has an improved/consolidated interface for CMIS,
using the OpenCMIS API from Apache Chemistry project.

But the most serious change is that the time zone handling has changed, and the search from OpenWorkdesk does not get the correct result anymore.

By CMIS 1.0 spec it is defined that a Date(time) value should be provided in following notation:
<datetime literal> ::= TIMESTAMP <quote> <datetime string> <quote>
<datetime string> ::= YYYY-MM-DDThh:mm:ss.sss[Z | +hh:mm | -hh:mm]
e.g. TIMESTAMP'2012-03-11T23:00:00.000Z'

The OpenWorkdesk identifies (more guess Smiley Wink  ) the client timezone and convert the provided date into Zulu (UTC) and send it to the server.

Is Alfresco 4.0 in another time zone as the date value is defined, the Alfresco server will not return any results. Does any one encounter the same problems?
6 REPLIES 6

vahe
Champ in-the-making
Champ in-the-making
Hi D.evil,

:idea: Change the time zone of the server into the UTC (Zulu) time zone and re-index your values.
Why are you converting the date values into UTC time zone and do not provide it as is?

Cheers

d_evil
Champ in-the-making
Champ in-the-making
I had also such solution in mind, but the search was working fine with an Alfresco 3.4 system. Will try your suggestion and give feedback afterwards.

Regarding your question
Why are you converting the date values into UTC time zone and do not provide it as is?

The most ECM systems are saving date values using UTC and since with CMIS you don't get any information about the server time zone, it was just the best idea to convert it into that time zone.
Also it looks like it was a wise decision to do so, since the "client" (OpenWorkdesk is more a middleware) can control the conversion (maybe a new configuration parameter is needed here?). An optional configuration parameter would not need to change anything on your server and it would work correctly.

chfi
Champ in-the-making
Champ in-the-making
Hi Guys,
for the customized fields and also for some special fields (like cm:created,…), the index gets just the date and not the time from the backend system. To change this behavior you just have to modify the property file for query analyzers (dataTypeAnalyzers.properties). Change the value in the following way:

d_dictionary.datatype.d_datetime.analyzer=org.alfresco.repo.search.impl.lucene.analysis.DateTimeAnalyser

But keep in mind that this affects all of the fields from the type d:date. So this change will affect your system.

d_evil
Champ in-the-making
Champ in-the-making
Changed the time zone where Alfresco is installed and re-indexing seemed to be done, now the search return some results.

But I must say that the system specific date values cannot be searched, or at least they are not returned. I don't know why and it is not a problem in OWD, looks like Alfresco changed something in the 4.0 so that system properties which are of type date/datetime cannot found through a CMIS search.

The parameter information is nice thanks.
:?: If Alfresco does not provide the time to the indexer, then basically the time zone should not have any effect on the search  :!:

Need to do some more testing, maybe it's the new behavior of Alfresco 4.0.

Thank you guys

7joeblack8
Champ in-the-making
Champ in-the-making
Hi there,


maybe this discussion would fit my problem…

i had a property date db value of the alfresco-postgres like this:

"1970-12-15T00:00:00.000+01:00"


why during a search for the resulting documenti, the OWD search shows me:

"14-12-1970"?  :roll:

it's just one day before…i don't understand…the value on the db looks correct…the problem is Alfresco 4 or the OWD?

thanks in advance

d_evil
Champ in-the-making
Champ in-the-making
Hi Black.Jack,

I think it's a similar problem, for verification if OWD or Alfresco-CMIS is working different I use the OpenCMIS Workbench http://chemistry.apache.org/java/opencmis.html.

You could send a simplified search using the Query-Dialog of the application, the result can be compared with the one from OWD.

I know OWD is trying to convert date values from server into a client time zone.
Therefore it would be interesting what date value is returned and more important which time zone is associated with it.

Regards,
D.evil