question

Upvotes
5 1 3 4

how to configure QueryStartDate and QueryEndDate in TickHistoryTimeAndSalesExtractionRequest

Hello,

how to configure QueryStartDate and QueryEndDate in TickHistoryTimeAndSalesExtractionRequest to be in local datetime ? Because I think that the API consider QueryStartDate and QueryEndDate to be on GMT , all the time.

In my case, I am trying to get Auction Price Data from the Australian Market , for example ric IOF.AX :

I did this :

.put("Condition", new JSONOrderedObject()

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

put("QueryStartDate", "12:00:00")

.put("QueryEndDate", "23:59:59")

The result is not correct

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

IOF.AX,Market Price,2017-08-29T09:04:19.884988294+10,Auction,4.5,2326

Why is not correct ? because 2017-08-29T09:02:13.369484903+10 ( GMT+ offset) means that this auction was sent 2017-08-28T23:02:13.369484903Z australian local time,however the australian market closes at 16:30:00!

Someone can help here ?

Thanks

tick-history-rest-apitick-data
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
426 2 4 4

@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

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
5 1 3 4

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
426 2 4 4

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")

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
5 1 3 4

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.