XAU= has no time stamp (EMA Java API)

hujunhu

Hi, I am using EMA to get market price data. Most of the instruments I am using is fine except "XAU=".

I cannot get time stamp for it.

I used "QUOTIM" and "QUOTE_DATE" to get time stamp. May I know why? and how to solve it?

Thank you.

pimchaya.wongrukun01

Hello @hujunhu

The number in brackets(5) and (17) are the field id of TIMACT
and ACTIV_DATE respectively. You can find the fields’ info including their type
in RDMFieldDictionary shipped with EMA package:

The type(the 7th column) of TIMACT are TIME(DataTypes.TIME) and the
type of ACTIV_DATE is DATE(DataTypes.DATE). You can refer to consumer.series200.example200__MarketPrice__Streaming
which demonstrate how to decode a field according to its type. The example output:

Item Name: XAU=
Service Name: API_ELEKTRON_EPD_RSSL
Fid: 3 Name = DSPLY_NAME DataType: Rmtes Value: 
Fid: 5 Name = TIMACT DataType: Time Value: 9:55:0:0
Fid: 11 Name = NETCHNG_1 DataType: Real Value: 0.82
Fid: 17 Name = ACTIV_DATE DataType:Date Value: 4 / 1 / 2018
….

Tim Smith

Hi @hujunhu it looks like this RIC is on a very old data model. The quote date and time fields are not used in this template (I will do some digging to find out why as it should be on the same data model at the spot currency RICs like GBP= and use the better precision QUOTIM_NS fields).

This RIC uses TIMACT (5) and ACTIV_DATE (17) as its date fields currently.

Tim

hujunhu

https://community.developers.refinitiv.com/discussion/comment/22744#Comment_22744

Hi Tim,

Do you mean I should use QUOTIM_NS for better precision?

What data type are these two date fields (e.g. DataTypes.INT)?

What are those number in brackets? (5) and (17)

Thank you!

Jun

Tim Smith

https://community.developers.refinitiv.com/discussion/comment/22747#Comment_22747

QUOTIM_NS will be used by us for better precision (up to nano), but in the case of this instrument the field isn't being used.We need to update the data model for it to be able to publish.

I not an expert in this particular API - just the data that is sent to it - but we send the data for TIMACT in time format not an integer or such like. QUOTIM_NS is sent in integer format, so its possible it will be for this API. But id need an API specialist to comment on that part ideally.

The numbers in the brackets are the field numbers. We have a field name and a field number for all our realtime data.

hujunhu

https://community.developers.refinitiv.com/discussion/comment/22806#Comment_22806

@pimchaya.wongrukun01

Thanks. However, the precision of TIMACT seems to be in minutes. May I know why? And how to get a more precise timestamp? Thanks.

Regards,

Jun

pimchaya.wongrukun01

https://community.developers.refinitiv.com/discussion/comment/22828#Comment_22828

Hello hujunhu,

I do not know why the feed sends TIMACT to be in minutes. To get a more precise timestamp is depends on the feed; if it sends more precise timestamp for this RIC and on which field.

pimchaya.wongrukun01

https://community.developers.refinitiv.com/discussion/comment/22828#Comment_22828

Hello hujunhu,

I suggest you ask these questions with the feed/data support team who can provide you with the proper answers. You can submit the query to the data team directly via https://my.thomsonreuters.com/
After you log in, click "RAISE A CASE" then "Product Support". Then, select your subject e.g. “I cannot find content I am looking for”. At “Select product”, select the feed e.g. “Thomson Reuters Elektron Real-Time”. If you cannot access the web site or submit the query, you should send an email to rdc.administrator@thomsonreuters.com

Tim Smith

https://community.developers.refinitiv.com/discussion/comment/22828#Comment_22828

TIMACT is an old field with a very low precision and cant be increased. It has been replaced by newer higher precision fields which are being added to instruments across our Elektron network. XAU= hasnt had these fields added as yet, but I am in the process of requesting it. TIMACT would likely be replaced by QUOTIM_NS which allows up to nanosecond precision (though its unlikely it would publish to that level of precision).