how to configure QueryStartDate and QueryEndDate in TickHistoryTimeAndSalesExtractionRequest

wajdi.benslimane-ext
wajdi.benslimane-ext Newcomer
in TRTH

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

Tagged:

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In
Register

Answers

  • steven.peng
    steven.peng LSEG

    @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

  • wajdi.benslimane-ext
    wajdi.benslimane-ext Newcomer

    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.

  • steven.peng
    steven.peng LSEG

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

  • wajdi.benslimane-ext
    wajdi.benslimane-ext Newcomer

    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.

  • wajdi.benslimane-ext
    wajdi.benslimane-ext Newcomer

    Hi, the subject related to my question is a use case that it has not been considered by TRTH V2. However, it is under investigation now by the Reuters teams. So, you can keep this question open until a fix is made or I can close it as not answered .

    B.R.

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In
Register

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In
Register

Quick Links

Categories