Engine-rest date format bug

Between 7.7.0 and 7.8.0 version I came across a bug related to date parsing.

while 7.7.0 engine rest has no issue with the date fomat like this one (in line with the documentation)


7.8.0 fails with the f9ollowing error. It needs the full date format. The document needs to be updated or this needs to be fixed.

Caused by: com.fasterxml.jackson.databind.exc.InvalidFormatException: Can not construct instance of java.util.Date from String value ‘2018-02-08T13:42:19’: not a valid representation (error: Failed to parse Date value ‘2018-02-08T13:42:19’: Unparseable date: “2018-02-08T13:42:19”)
at [Source: “2018-02-08T13:42:19”; line: 1, column: 1]
at com.fasterxml.jackson.databind.exc.InvalidFormatException.from(InvalidFormatException.java:55)
at com.fasterxml.jackson.databind.DeserializationContext.weirdStringException(DeserializationContext.java:907)
at com.fasterxml.jackson.databind.deser.std.StdDeserializer._parseDate(StdDeserializer.java:787)
at com.fasterxml.jackson.databind.deser.std.DateDeserializers$DateBasedDeserializer._parseDate(DateDeserializers.java:175)
at com.fasterxml.jackson.databind.deser.std.DateDeserializers$DateDeserializer.deserialize(DateDeserializers.java:261)
at com.fasterxml.jackson.databind.deser.std.DateDeserializers$DateDeserializer.deserialize(DateDeserializers.java:245)
at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3736)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2726)
at org.camunda.bpm.engine.rest.dto.converter.JacksonAwareStringToTypeConverter.mapToType(JacksonAwareStringToTypeConverter.java:38)
… 49 more


We introduce time zone support within 7.8 so you need to add time zone info

By default*, the date must have the format yyyy-MM-dd’T’HH:mm:ss.SSSZ, e.g., 2013-01-23T14:42:45.435+0200.
*For further information, please see the documentation.

Hope this helps.

Best regards,


I also have a problem with the date format. We are using version 7.8 so considering the documentation I should be using following request url to get all tasks with a followUp date before the given date:


I, however, receive following error message:
{“type”:“InvalidRequestException”,“message”:“Cannot set query parameter ‘followUpBefore’ to value ‘2018-04-05T23:59:59.000 02:00’: Cannot convert value “2018-04-05T23:59:59.000 02:00” to java type java.util.Date”}

What am I doing wrong? The date format seems to be the same as in the documentation?

Hi Dimitris,

It seems that you’ve got interval between the date and the timezone 2018-04-05T23:59:59.000 02:00.
I guess that could lead to problems. Could you please confirm that you request is

Best regards,


I included a screenshot. Basically I just want all tasks with a followUp date for that day, no matter the time.
What exactly do you mean with interval between the date and timezone?

Hi Dimitri,

I’m sorry, my bad.
I tried it and it is not working without quotes. Please check:
or try post query.
I will create bug report to change the documentation.

Best regards,

Hi Yana,
That works! Thank you for your help.

Kind regards


After I moved to 7.8 version and changed the code to support the time zone it is not working. Please see the attached screenshot. I have the date as
and the query to fetch the historical task list is

The query still returns the task with due date “due”: “2018-08-23T00:00:00.000-0400”

What am I missing here?

If you provide 2018-01-02T09:45:00.000+00:00 (or escaped as 2018-01-02T09:45:00.000%2B00:00, or 2018-01-02T09:45:00.000 or 2018-01-02…) to the engine-rest/metrics endpoint, you get an error of the form:

    "type": "InvalidRequestException",
    "message": "Cannot convert value \"2018-01-02T09:45:00.000 00:00\" to java type java.util.Date"

However, if you provide 2018-01-02T09:45:00.000UTC or 2018-01-02T09:45:00.000+0000 (or escaped as 2018-01-02T09:45:00.000%2B0000) to the same endpoint, you get something useful:

        "timestamp": "2018-09-08T00:15:00.000+0000",
        "name": "activity-instance-end",
        "reporter": "xx.xx.xx.xx$default",
        "value": 87

Valid textual timezones appear to be limited to UTC or GMT (but curiously NOT Z), or 4-digit values with NO colon (e.g., -0800, +0100, etc.) Timezone specifiers with a colon (+02:00) are invalid here (though you’d think ISO8601 standard dates would be supported!)

If you’re using something like Postman or curl to sent the query, be sure to URL escape that + or - as %2B or %2D respectively, e.g.:

curl -i 'localhost:8080/engine-rest/metrics?name=activity-instance-end&startDate=1970-01-01T01:45:00.000%2B0200'

I hope this helps - while the docs appear to be accurate, the lack of the colon in the timezone is important (despite ISO), as is proper escaping when necessary.

tl;dr - ISO8601 datetimes look like 2008-09-15T15:53:00+05:00 and 20080915T155300+0500. Camunda seems to use a mashup of the two formats (with milliseconds added) for a resulting format of 2008-09-15T15:53:00.000+0500 (sign may need URL escaping) or 2008-09-15T15:53:00.000UTC.


Could you please share the regex (date format ) for the same.

Hi @Yana ,
Here we are getting issue for the date https:/domain-name/engine-rest/external-task?lockExpirationAfter=2020-03-20T04:59:28.000+0000 , When we are calling camunda

Awaiting for your reply

Thanks & Regards

Hi @Tanmay_Naik,

The + needs to be escaped, please check what Mart wrote earlier:

1 Like

Thanks @Yana , Appreciated your quick presence

This bug re-appeared again… I had to provvide the following Date Format for Jackson: