Engine-rest date format bug

adat · February 8, 2018, 8:03pm

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)

/engine-rest/task?dueAfter=2018-02-08T13:42:19&active=true

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

Yana · February 9, 2018, 6:10am

Hello,

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,
Yana

DimitrisD · April 5, 2018, 8:06am

Hi,

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:

task?followUpBefore=2018-04-05T23:59:59.000+02:00

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?

Yana · April 5, 2018, 9:07am

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
task?followUpBefore=2018-04-05T23:59:59.000+02:00

Best regards,
Yana

DimitrisD · April 5, 2018, 9:17am

Hi,

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?

Yana · April 5, 2018, 11:44am

Hi Dimitri,

I’m sorry, my bad.
I tried it and it is not working without quotes. Please check:
\task?followUpBefore="2018-04-05T23:59:59.000+02:00"
or try post query.
I will create bug report to change the documentation.

Best regards,
Yana

DimitrisD · April 5, 2018, 11:47am

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

Kind regards

adat · June 20, 2018, 3:49pm

@yana.vasileva

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
“2020-04-05T23:59:59.000+02:00”
and the query to fetch the historical task list is
task?taskDueDateAfter=“2020-04-05T23:59:59.000+02:00”&active=true.

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

What am I missing here?

MartyMacGyver · September 8, 2018, 1:15am

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.

sanjay.chaurasia · February 6, 2020, 4:49am

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

Tanmay_Naik · March 20, 2020, 8:24am

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
Tanmay

Yana · March 20, 2020, 8:29am

Hi @Tanmay_Naik,

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

Tanmay_Naik · March 20, 2020, 8:36am

Thanks @Yana , Appreciated your quick presence

zambrovski · July 1, 2021, 9:23am

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

SimpleDateFormat("yyyy-MM-dd'T'hh:MM:ss.SSSz")