@wajdi.benslimane-ext,

When the "MessageTimeStampIn" is set to "LocalExchangeTime", as you did, the returned time stamp is represented in the local exchange time. In your example:

IOF.AX,Market Price,2017-08-29T09:02:13.369484903+10,Auction,4.5,1159

the acution was sent at 9:02 am of Aug 29 AEST time. "+10" representatives it's off set from GMT so the equivalent GMT time should be AEST time minus 10 hours as Aug 28 23:02.

If you change "MessageTimeStampIn" to "GmtUtc" and do the same extraction, you should get the same auction data with GMT time stamp as:

IOF.AX,Market Price,2017-08-28T23:02:13.369484903Z,Auction,4.5,1159

IOF.AX,Market Price,2017-08-28T23:04:19.884988294Z,Auction,4.5,2326

Hello Steven,

I need to precise a detail : My request is

.put("Condition", new JSONOrderedObject()

.put("MessageTimeStampIn", "LocalExchangeTime") .put("ApplyCorrectionsAndCancellations", true).put("ReportDateRangeType", "Range") .

put("QueryStartDate", "2017-08-28T12:00:00")

.put("QueryEndDate", "2017-08-28T23:59:59")

So when I get a response :

IOF.AX,Market Price,2017-08-29T09:02:13.369484903+10,Auction,4.5,1159

I suppose that there is something wrong : because I am asking for Auction of the local date 2017-08-28 but I am receiving an auction price, with local date , 2017-08-29.

I think this is an issue within the new version.

QueryStartDate and QueryEndDate should be in UTC time. MessageTimeStampIn is only for time-stamps on extracted data. So if your need auction of Aug 28 between 12:00 and 23:00 local time time, it is GMT 02:00-13:00 and should be:

.put("QueryStartDate", "2017-08-28T02:00:00.000")

.put("QueryEndDate", "2017-08-28T13:59:59.000")

I see your point. I've already thought about this solution. But I see here a big regression between TRTH V1 and TRTH V2.

In the previous version, and for the auction , I didn't care about the market, or its timezone ! I create a request and I set this parameter req.setRequestInGMT(false ) for Auction.

In TRTH V2, this parameter has disappeared , leaving us, the client of Reuters, in big trouble because in our migration project expected the same quality from the V2, and which is not.

I guess that Reutrers dev team should take care of this issue: adding a requestInGMT parameter.