Create time of a Task is not retrieved correctly from database


My problem is related to the fact that the create time of a task is not retrieved correctly from database.
I did a select on ACT_RU_TASK table and I saw that the value is stored OK, but when retrieved using TaskRestService, what getCreateTime() method of Task returns is NOK(in my case is two days ago).
I also saw that the problem persist if I look for these tasks using camunda tasklist.

I am using camunda-bpm-platform-7.4.0 and the database server is SQL Server 2014.

Any suggestion would greatly help!

Best regards,
Bogdan Tatar

Hello again,

What I did was to take a clean snapshot of wildfly-8.2.1.Final configured with camunda.
I started the server, logged in with the default demo user, got to the task list page and created a task for the demo user.When the details of the task were displayed, the create time date was displayed OK.
Then I configured wildfly server with mssql and connected it to a database made on a mssql server by using the scripts from ‘org.camunda.bpm.engine.db.create’ package. I then did the same steps and when the details of the task were displayed, the create time date was displayed NOK(in the database it was stored OK).
From the investigations I did, I can say that the value is already altered when retrieved by the SQLServerResultSet, but I can not say how is this happening, as I need to get deeper inside mssql implementation, thing that I would really not want to do.
I tested using sqljdbc4.jar and sqljdbc4-3.jar driver.
So if you have any suggestions please let me know.

Best regards,
Bogdan Tatar

Hi Bogdan,

Can the problem be related to timezones? I.e. MS SQL stores (and displays) the value in a different time zone than is returned by the Camunda REST API or the way it is displayed by java.util.Date#toString?

If you are able to extract a unit test (see the template, then we can try to reproduce the problem and help you track it down.


Hi Thorben,

Thanks a lot for the reply.
What I did in the end was to take from Nexus the last official distribution of the sqljdbc driver from Microsoft, which is sqljdbc4-4.0, and it finally worked OK.

Best regards,
Bogdan Tatar

1 Like

Thanks for sharing the solution :slight_smile: