Trade Date Conversion to Timestamp in Seconds

Hello,

In our feeds from America, FID "TRADE_DATE" had value 1602734400 for "15 Oct 2020". This corresponded to GMT: Thursday, October 15, 2020 4:00:00 AM, or Thursday October 15, 2020 00:00:00 (am) EST. However TRADE_DATE of the same feeds from Hong Kong had 1602691200, which corresponded to GMT: Wednesday, October 14, 2020 4:00:00 PM. So what is the logic behind this? What logic should we apply so they're the same in GMT?

Both America and HK uses ELEKTRON EDGE RFA C++ API 8.x.x.

Thanks,

Find more posts tagged with

trep

rfa

trade

elektron-sdk

rfa-api

Accepted answers

zoya faberov

Hello @jzhao,

Thanks following up on this topic, and for confirming that there is no issue with content, it's as expected.

On my side, from API consumer access viewpoint, RFA code that accesses content is the same, not different per exchange. RFA API is just the means of access, the content as seen would be the same, if accessed via another realtime API, for example, EMA.

If this helps,

I just tested with StarterConsuemr example that came with RFA C++ 8.0 SDK:

IBM.N ( NYSE)
FieldEntry [    16] TRADE_DATE  11/6/2020

and

7500.HK
FieldEntry [    16] TRADE_DATE  11/6/2020

I understand your point, that TRADE_DATE as published may mean different actual time for different exchanges, however, the exchange fully controls the content that they provide. As a developer and designer, we are in control of the interpretation and presentation, and can also include local time zone as part of information supplied to the business tier of the consumer app.

Therefore, I believe the behavior from RFA is confirmed to be as expected.

All comments

zoya faberov

Hello @jzhao,

My understanding is that you would like to verify that the content, as provided by ELEKTRON service, is inconsistent across exchanges.

My personal opinion is that as different exchanges provide the content published, it's totally within their domain what and how to make available, and this causes discrepancies such as you observe.

However, the majority of the members of this forum are Refinitiv API developers, the moderators of this forum are experts in Refinitiv API. For the definitive answer on suspected content issues, the best way is to address them as a customer is to raise them directly with Refinitiv Content Helpdesk Online, this way the query will be immediately assigned to an appropriate Refinitiv content expert.

Please let us know if you are able to proceed, or I can help submit on your behalf?

jzhao

Hi Zoya,

I did raise it to Refinitive, Case : 09259693. However I was asked to address the question here:

"Based on our Specialist advise, "epoch" time needs to be consulted with our Developer community. You can raise your query through the following link:

https://developers.refinitiv.com/en"

Yes if you could, please raise it again. Thank you very much.

zoya faberov

Hello @jzhao,

Thanks following up on this topic, and for confirming that there is no issue with content, it's as expected.

If this helps,

I just tested with StarterConsuemr example that came with RFA C++ 8.0 SDK:

IBM.N ( NYSE)
FieldEntry [    16] TRADE_DATE  11/6/2020

and

7500.HK
FieldEntry [    16] TRADE_DATE  11/6/2020

Therefore, I believe the behavior from RFA is confirmed to be as expected.

EXPLORE OUR SITES