Dear wM experts,

We have created request and response documents using RAD in wM 10.15 with RAML provided by BA team, due to that date was auto set as java.utl.Date type in request document. We cannot ask to change the RAML as that is owning by separate team and the same RAML is imported in API gateway as well.

Here the problem is we have an existing logic where we are calculating date difference and for that expecting date in “dd-MM-yyyy” format but due to java.util.Date type, we are getting date in “MM/dd/yyyy, hh:mm:ss”.

Since we have this date difference calculation in multiple places, we dont want to add additional step to transform runtime util date, instead we are looking for any property setting in extended settings to change the format of UTIL date in runtime when it reaches to wM.
Kindly help to resolve this issue.

Version : webMethods 10.15

Don’t try to parse the java.util.Date object. The string and format you see in Designer debug is the “toString” representation of the object, using the JVM/OS default format.

Use services that accept a java.util.Date object for the calculation, not strings. Create a utility Java service as a utility for this.

Another option is to convert the java.util.Date object to a string using pub.date:formatDate and pass those to pub.date:calculateDateDifference.

I would suggest creating your own Java service that uses Java library methods to calc the diff of the 2 objects.

Thanks for the reply reamon,
Yes, with formatDate I converted the format and proceeding with time diff. calculation for time being.
We are actually looking for different option i.e., when it reaches to wM, IS should take in expected format(i.e., dd-MM-yyyy) than the Util date format and for that is there any way we can add/modify property at IS level extended settings or in any other place?

Lets assume there is a setting that can override the datetime parsing behavior, are you absolutely sure that you want to modify how IS behaves on top level? What do you think will happen to the other datetime objects then? Changing extended settings for these kind of scenarios is not a good idea. Using a util java service or using the DateTimeFormat service as Rob suggested is the right way IMO. What you are suggesting is bad on so many ways. The requirement you have can be implemented with 2 - 3 lines of a java service.

Agreed with the points, mainly about changing a server-wide extended setting being risky. Would need to make sure everything affected would be okay or adjusted.

But there may be a setting at the service level. But since this is a RAD component and is likely limited, seems there is a good chance there isn’t.

IS does take in expected format – dd-MM-yyy. It converts it to a Java object. There is no such thing as a “Util date format” . java.util.Date is an object, not a string.

If you want IS to not convert the JSON element string to an object you may have to avoid using RAD components. I avoid RAD (and WSD) almost always. They get in the way more than they help, IME.

Because I don’t use RAD (I use the v1 approach) I don’t have any tips about how to force IS to not convert the JSON string to the java.util.Date object. But 10.15 JSON support does include the ability to keep elements as strings when parsing JSON to an IS document so perhaps there is a flag or setting available. Perhaps someone else in the community has applicable info.