FIDs SALTIM_NS (14266) and TIMACT_NS (14269) given in per-second resolution?

philipbalfour · February 2

Hello LSEG,

I have a developer who is using rfa7.6.2.L1.linux.rrg Library and Marketfeed protocol.

They are looking at example ric code ERST.VI and the fields SALTIM_NS (14266) and TIMACT_NS (14269).

Although these fields are meant to be available with nanosecond precision, they say they receive a number which seems to be in seconds:

We don't use the OMM protocol but Marketfeed.

I suppose that we should not have an issue if we only have seconds in the time stamp.

However, we need the confirmation that the FIDs 14266 and 14269 always contain the number of seconds since UTC midnight. In the Marketfeed messages we can only see an integer value and we have no further information whether this value equals to the number of seconds, milliseconds or nanoseconds.

Following an example message received around 08:03 UTC.

UPD<FS>316<US>XX<GS>ERST.VI<US>41552<RS>31<US>+283<RS>22<US>+36.190<RS>14269<US>28995<RS>1025<US>08:03:15<RS>30<US>+175<RS>14265<US>28995<RS>5<US>08:03<FS>

The FID 14269 of the message above contains the value 28995 which equals to 8 * 3600 + 3 *60 + 15 -> 08:03:15 UTC.

I am not sure why they only get seconds (and not the milli/nano second part), however is it right that this is the number of seconds since UTC midnight? Seems to match the other fields in the marketfeed protocol message.

Thanks, Phil

Jirapongse · February 5

@philipbalfour

Thank you for reaching to us.

According to the Coding For High Precision Time article, the existing RFA MarketData (MarketFeed) applications will not have access to the high precision time values.

You are correct. It is the number of seconds since UTC midnight but the market feed doesn't suppot the high precision time values.

You need to use the OMM interfaces with RFA 8.x or Refinitiv Real-Time SDKs.

I suggest using the Refinitiv Real-Time SDKs which are the strategic APIs. You can also refer to the following articles.

philipbalfour · February 6

@Jirapongse thanks very much for the information -- I have forwarded this to the developers and no further questions for now. Thanks again for your great support, best regards, Phil

philipbalfour · February 7

@Jirapongse followup question from dev:

"I am wondering if you could advise how to interpret a 0 value in these two fields. I assume that it's a blank value so that the specific information is not available.

However, it could also mean 0 seconds since UTC midnight."

Does zero represent a time of exactly UTC midnight? If a value is not available, then how would the blank/null value be represented in this field? Thx Phil

Jirapongse · February 7

As far as I know, +0 represents a blank value in Market Feed.

ACVOLTM_MS (14256) and OFF_CLS_MS (14258) are +0.

SALTIM_NS (14266), OFF_CLS_NS (14323), and ACVOL_UNS (32743) are 0.

According to the values in ACVOLTM_MS and OFF_CLS_MS, those fields should be blank too.

You may need to check other time fields, such as TIMACT (5) or SALTIM (379).

philipbalfour · February 8

Hello @Jirapongse

The developer asked how to interpret a zero in these fields? Does it mean UTC midnight, or does it mean blank/null? See below:

I am wondering if you could advise how to interpret a 0 value in these two fields. I assume that it's a blank value so that the specific information is not available.

However, it could also mean 0 seconds since UTC midnight.

As an example, please find bellow some messages received yesterday for .BCOMEUTR.

IMG<FS>340<US>XX<GS>.BCOMEUTR<US>77<US>40928<RS>1<US>2923<RS>2<US>125<RS>3<US>BBG Euro TR<RS>4<US>22<RS>6<US>+285.8891<RS>7<US>+285.8891<RS>8<US>+285.5429<RS>9<US>+285.5164<RS>10<US>+285.5429<RS>11<US>-0.0000<RS>12<US>+285.8891<RS>13<US>+283.8542<RS>14<US>1<RS>15<US>978<RS>16<US>0

5 FEB 2024<RS>18<US>00:00<RS>19<US>284.6385<RS>21<US>+285.8891<RS>28<US><RS>29<US> : <RS>32<US>+0<RS>53<US>4<RS>56<US>-0.0000<RS>77<US>+6197<RS>78<US>0<RS>79<US>05

FEB 2024<RS>90<US>+290.0586<RS>91<US>+279.1104<RS>92<US>+321.0012<RS>93<US>+278.0916<RS>94<US>+415.8330<RS>95<US>

112.1900<RS>98<US>+282.1984<RS>110<US>1<RS>111<US>1<RS>178<US>+0<RS>201<US>03 JUL 2008<RS>202<US>08

JUL 2009<RS>259<US>118<RS>285<US>03:00<RS>286<US>20:25<RS>287<US>14:52<RS>350<US>01 FEB 2024<RS>351<US>08 JAN 2024<RS>372<US>+0<RS>379<US>00:00:00<RS>383<US>+0<RS>728<US><RS>759<US>

+290.0586<RS>760<US>+284.0420<RS>761<US>+289.4395<RS>869<US>0<RS>996<US>+285.8891<RS>997<US>+290.0586<RS>998<US>+284.0420<RS>999<US>+289.4395<RS>1000<US>CLS<RS>1021<US>+15149145<RS>1025<US>

: : <RS>1028<US>05 FEB 2024<RS>1031<US>-0<RS>1032<US>+6200<RS>1033<US>+0<RS>1034<US>+285

.8891<RS>1075<US>0<RS>1076<US>0<RS>1080<US>}A@<RS>1704<US> : <RS>1709<US>22<RS>1791<US>2<RS>2335<US>+0<RS>3263<US><RS>3265<US>+0<RS>3266<US>+0<RS>3372<US>+285.8891<RS>3397<US>+0<RS>3422<US>BCOMEUTR<RS>3448<US>

<RS>3449<US>1<RS>3450<US> <RS>3451<US>1<RS>3852<U

S><RS>3853<US>0<RS>3854<US>0<RS>3984<US><RS>4043<US>0<RS>4465<US>CLS<RS>4466<US>CLS<RS>4467<US><RS>4468<US><RS>4469<US><RS>5357<US>+3771<RS>6258<US>+10809901<RS>6259<US>+73541077<RS>6260<US>+53549731<RS>6401<US>[@B<RS>6480<US>.[SPSCMEI01ML1<RS>6614<US>1<RS>6762<US>05

FEB 2024<RS>6

975<US>6200<RS>8300<US><RS>8635<US><RS>8647<US>5<RS>8927<US>5<RS>14158<US>0<RS>14159<US>

UPD<FS>316<US>XX<GS>.BCOMEUTR<US>40976<RS>286<US>20:25<RS>19<US>+284.6385<RS>6258<US>+10809901<RS>285<US>03:00<RS>379<US>03:00:09<RS>3984<US><RS>6614<US>1<RS>1021<US>+16989359<RS>14266<US>10809<RS>6<US>+285.4307<RS>77<US>+1<RS>6259<US>+73541077<RS>3854<US>+10809902<RS>4465<US><RS>

8927<US>8<RS>11<US>-0.4584<RS>287<US>14:52<RS>13<US>+283.8542<RS>1000<US><RS>12<US>+285.8891<RS>3422<US>BCOMEUTR<RS>18<US>03:00<RS>14<US>2<RS>16<US>06

FEB 2024<RS>56<US>-0.1603<RS>6260<US>+53549731<RS>3853<US>+10809902<RS>8647<US><FS>

UPD<FS>316<US>XX<GS>.BCOMEUTR<US>40992<RS>110<US>1<RS>111<US>1<RS>3449<US>1<RS>3451<US>1<FS>

UPD<FS>316<US>XX<GS>.BCOMEUTR<US>41008<RS>77<US>+2<RS>6<US>+285.4554<RS>14266<US>10819<RS>18<US>03:00<RS>3422<US>BCOMEUTR<RS>3854<US>+10819637<RS>6614<US>1<RS>14<US>1<RS>1021<US>+16991294<RS>56<US>-0.1517<RS>8647<US><RS>3984<US><RS>8927<US>8<RS>4465<US><RS>1000<US><RS>11<US>-0.433

7<RS>379<US>03:00:19<RS>3853<US>+10819637<FS>

UPD<FS>316<US>XX<GS>.BCOMEUTR<US>41024<RS>77<US>+3<RS>6<US>+285.4545<RS>14266<US>10829<RS>18<US>03:00<RS>3422<US>BCOMEUTR<RS>3854<US>+10829824<RS>6614<US>1<RS>14<US>2<RS>1021<US>+16993216<RS>56<US>-0.1520<RS>8647<US><RS>3984<US><RS>8927<US>8<RS>4465<US><RS>1000<US><RS>11<US>-0.434

6<RS>379<US>03:00:29<RS>3853<US>+10829824<FS>

UPD<FS>316<US>XX<GS>.BCOMEUTR<US>41040<RS>77<US>+4<RS>6<US>+285.4561<RS>14266<US>10839<RS>18<US>03:00<RS>3422<US>BCOMEUTR<RS>3854<US>+10839527<RS>6614<US>1<RS>14<US>1<RS>1021<US>+16995009<RS>56<US>-0.1515<RS>8647<US><RS>3984<US><RS>8927<US>8<RS>4465<US><RS>1000<US><RS>11<US>-0.433

0<RS>379<US>03:00:39<RS>3853<US>+10839527<FS>

UPD<FS>316<US>XX<GS>.BCOMEUTR<US>41056<RS>77<US>+5<RS>6<US>+285.4295<RS>14266<US>10849<RS>18<US>03:00<RS>3422<US>BCOMEUTR<RS>3854<US>+10849715<RS>6614<US>1<RS>14<US>2<RS>1021<US>+16997009<RS>56<US>-0.1608<RS>8647<US><RS>3984<US><RS>8927<US>8<RS>4465<US><RS>1000<US><RS>11<US>-0.459

6<RS>379<US>03:00:49<RS>3853<US>+10849715<FS>

I look forward to your reply.

Jirapongse · February 9

@philipbalfour

This is the raw data extracted from the LSEG Tick History. The data is in OMM.

.BCOMEUTR,Market Price,2024-02-05T20:50:11.573289296Z,-6,Raw,UPDATE,UNSPECIFIED,,,,2923,,40896,,30
,,,,FID,1028,,GV1_DATE,2024-02-05,
,,,,FID,6762,,OFF_CLS_DT,2024-02-05,
,,,,FID,79,,HSTCLSDATE,2024-02-05,
,,,,FID,286,,HIGH_TIME,20:25:41.000000000,
,,,,FID,3984,,TRD_TYPE,,
,,,,FID,8647,,PERIOD_CD2,5,
,,,,FID,3853,,TRDTIM_MS,73541077,
,,,,FID,6259,,HIGH_T_MS,73541077,
,,,,FID,14266,,SALTIM_NS,20:25:41.077000000,
,,,,FID,6,,TRDPRC_1,285.8891,
,,,,FID,1021,,SEQNUM,15144797,
.BCOMEUTR,Market Price,2024-02-05T20:50:45.253375523Z,-6,Raw,UPDATE,UNSPECIFIED,,,,2923,,40928,,18
,,,,FID,77,,NUM_MOVES,6197,
,,,,FID,6,,TRDPRC_1,285.8891,
,,,,FID,14266,,SALTIM_NS,00:00:00.000000000,
,,,,FID,18,,TRDTIM_1,00:00:00.000000000,
,,,,FID,3422,,PROV_SYMB,BCOMEUTR,
,,,,FID,3854,,SALTIM_MS,0,
,,,,FID,6614,,TRD_STATUS,1,"N "
,,,,FID,14,,PRCTCK_1,1,#DE#
,,,,FID,1021,,SEQNUM,15149145,
.BCOMEUTR,Market Price,2024-02-06T03:00:09.967616966Z,-6,Raw,UPDATE,CLOSING_RUN,,,,2923,,40958,,55
,,,,FID,32743,,ACVOL_UNS,,
,,,,FID,286,,HIGH_TIME,,
,,,,FID,383,,HST_VOL,,
,,,,FID,4469,,TRD_IND_5,,
,,,,FID,7,,TRDPRC_2,,
,,,,FID,14266,,SALTIM_NS,,
,,,,FID,1021,,SEQNUM,,
.BCOMEUTR,Market Price,2024-02-06T03:00:09.967616966Z,-6,Raw,UPDATE,UNSPECIFIED,,,,2923,,40960,,28
,,,,FID,286,,HIGH_TIME,20:25:41.000000000,
,,,,FID,19,,OPEN_PRC,284.6385,
,,,,FID,6258,,OPEN_T_MS,10809901,
,,,,FID,285,,OPEN_TIME,03:00:09.000000000,
,,,,FID,379,,SALTIM,03:00:09.000000000,
,,,,FID,3984,,TRD_TYPE,,
,,,,FID,6614,,TRD_STATUS,1,"N "
,,,,FID,1021,,SEQNUM,16989359,
,,,,FID,14266,,SALTIM_NS,03:00:09.902000000,

The SALTIM_NS was set to zero at 2024-02-05T20:50:45.253375523Z and set to blank at 2024-02-06T03:00:09.967616966Z via the closing run message.

philipbalfour · February 9

@Jirapongse thanks a lot! The developer is limited to using Marketfeed right now as this is an old application. He sees these fields only with per-second resolution. As you say, I think the "0" value he gets means null/blank in Marketfeed format (0 or +0 means blank, a real number zero would be -0). Thanks for your help! Cheers Phil

FIDs SALTIM_NS (14266) and TIMACT_NS (14269) given in per-second resolution?

Best Answer

Answers

Categories