Question about parsing exchtime value

Carfield Yim

Hi, I use below logic to parse exchange time SALTIM_MS / QUOTIM_MS:

var time_ms = java.lang.Long.parseLong(str)  
val nsec: Long = (time_ms % 1000)*1000000  
val seconds: Long = time_ms / 1000 % 60  
val minutes: Long = time_ms / 60000 % 60  
val hours: Long = time_ms / 3600000 % 24  
time = LocalTime.of(hours.intValue(), minutes.intValue(), seconds.intValue(), nsec.intValue())

But sometime there are value like this and have problem as value exceed long range:

java.lang.NumberFormatException: For input string: "18446744064486179580"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:67) ~[?:?]
at java.lang.Long.parseLong(Long.java:711) ~[?:?]
at java.lang.Long.parseLong(Long.java:836) ~[?:?]

What is the correct way to parse long value?

Jirapongse

@Carfield Yim

Thank you for reaching out to us.

Those fields contain a number of milliseconds in one day so their values should not exceed 86400000.

Did you check if the value is blank before accessing its value?

You may need to enable tracing in the API to verify the data. The tracing will impact the performance of the application.

Carfield Yim

https://community.developers.refinitiv.com/discussion/comment/125414#Comment_125414

Hi Jirapongse, thanks for getting back and yes, enable tracing is a concern, however, I do captured the whole message in string:

LCY.CHA, HashMap(OFFBK_TIM -> , CAN_VOL -> , RDNDISPLAY -> 18446744064486179580, OFF_CLS_NS -> 05:59:50.000255, TRDPRC_4 -> 0.0, NO_ASKMMKR -> 0.0, TRDPRC_5 -> 0.0, TRDTIM_1 -> 05:12:46, SPS_SP_RIC -> .[SPSCBOEAU01L1, OFFBK_PRC -> 0.0, INDAUC_NS -> , LOTSZUNIT2 -> AUD , DIV2_RATE -> 0.0, LONGLINK2 -> Cboe Australia, MPV -> 3DP , TRAN_PRICE -> 0.009000000000000001, TRDPRC_1 -> 0.009000000000000001, TRDPRC_2 -> 0.0, LONGLINK1 -> 0#EQB.CHA, OFFBK_DATE -> , TRDPRC_3 -> 0.0, PCTCHNG -> 0.0, 52W_LDAT -> 18 DEC 2024, YCHIGH_IND -> , CLOSE_ASK -> 0.0, YRHIGHDAT -> 22 JUL 2024, SALTIM_NS -> 05:12:46.495186, INDNAV_NS -> , PROV_SYMB -> LCY, PROD_PERM -> 18446744064486179580, YRLOWDAT -> 18 DEC 2024, EARNINGS -> -0.004, CLS_AUCVOL -> 0.0, EXCHTIM -> 06:13, DIVPAYDATE -> 15 OCT 2008, OFBKTIM_NS -> , IMB_SIDE -> , NAV_TM_NS -> , YCLOW_IND -> , SETTLEDATE -> , DELBY_DT -> , INAV -> 0.0, INGEST_DT -> 24 APR 2025, MAS_ID -> 0, NO_BIDMMKR -> 0.0, SALTIM_MS -> 18446744064486179580, ACVOL_UNS -> 304999, PERATIO -> 0.0, PRC_TICK -> 0.0, NETCHNG_1 -> 0.0, TRNOVR_UNS -> 2745.0, 52WK_HIGH -> 0.0184, CUM_EX_MKR -> XE , AGGRS_SID5 -> , TRDVOL_1 -> 304999.0, IRGTIM_NS -> , 52W_HIND -> , AGGRS_SID3 -> , TRD_TYP_NS -> 08:55:00.000150, AGGRS_SID4 -> , AGGRS_SID1 -> BID , AGGRS_SID2 -> , ASK -> 0.0, OFFBK_VOL -> 0.0, LOT_SIZE_A -> 1.0, SRC_SYMB -> LCY, MKT_SEGMNT -> AUS, PREF_DISP -> 18446744064486179580, TURNOVER -> 2745.0, TRVOLOFFBK -> , YIELD -> 0.0, OPN_AUCVOL -> 0.0, ACVOL_1 -> 304999.0, TRDVOL_2 -> 0.0, AMT_OS_UNS -> 9762042584, TRDVOL_3 -> 0.0, TRDVOL_4 -> 0.0, TRD_STATUS -> N , TRDVOL_5 -> 0.0, IRGDATE -> , RCS_AS_CL2 -> 302539, OFF_CD_IND -> AUS, ELIGBL_TRD -> Y , LIST_DATE -> 08 JUL 2008, NEWS_TIME -> , DBOR_DM_TP -> LCM , IRGTIM_MS -> , CLS_AUC -> 0.0, YRLOW -> 0.008, IMB_SH -> 0.0, RDN_EXCHD2 -> CHA, OFF_CLOSE -> 0.009000000000000001, HST_CLOSE -> 0.009000000000000001, 52WK_LOW -> 0.008, CAN_TIM_NS -> , NO_ASKORD1 -> , PREV_DISP -> 18446744064486179580, IRGVOL -> 0.0, TIMACT -> 08:55, ASKSIZE -> 0.0, CTRDTIM_MS -> , IND_AUCVOL -> 0.0, CAN_COND -> , BID_ASK_DT -> 24 APR 2025, OFFBK_COND -> , BIDSIZE -> 0.0, ADJUST_CLS -> 0.009000000000000001, INT_AUC -> 0.0, 52W_HDAT -> 22 JUL 2024, DSPLY_NAME -> LEGACYIRON FPO, NAVALUE -> 0.0, BCASTREF32 -> LCY.AX, PERIOD_CD2 -> C, VWAP -> 0.009000000000000001, HALT_DATE -> , TRADE_ID -> 78364464858, CLOSE_BID -> 0.008, SALTIM -> 05:12:46, QUOTIM_NS -> 06:13:00.095175227, IND_AUC -> 0.0, QUOTE_DATE -> 24 APR 2025, OPEN_PRC -> 0.009000000000000001, TR_TRD_FLG -> OB , NO_BIDORD1 -> , LOW_1 -> 0.009000000000000001, HSTCLSDATE -> 23 APR 2025, DIVIDEND -> 0.0, IRGPRC -> 0.0, TRADE_DATE -> 24 APR 2025, FRANKING -> 0.0, PHA_STM_NS -> 08:55:00.000150, SEE_RIC -> , PRCTCK_1 -> , PRC_QL_CD -> CLS, YRHIGH -> 0.0184, IND_AUCDT -> , MNEMONIC -> LCY, BCAST_REF -> LCY.AX, VWAP_VOL -> 304999.0, VEH_PERMID -> 81666075274, XMIC_CODE -> CHIA, RECORDTYPE -> 18446744064486179580, SYMBOL_FROM_SERVICE -> LCY.CHA, QUOTIM_MS -> 18446744064486179580, LOT_SIZE -> 1.0, 52W_LIND -> , ELG_TNOV -> 2744.991, NUM_MOVES -> 1.0, CAN_PRC -> 0.0, HIGH_1 -> 0.009000000000000001, OFF_CLS_DT -> 24 APR 2025, OPN_AUC -> 0.0, BID -> 0.0, NAVDATE -> , INST_PHASE -> C , CURRENCY -> AUD, INT_AUCVOL -> 0.0, EXDIVDATE -> , QUOTIM -> 06:13, DDS_DSO_ID -> 18446744064486179580, OFFCL_CODE -> LCY, ORDBK_VOL -> 304999.0, INGEST_NS -> 08:55:00.012505242, BR_LINK1 -> 0#EQB.CHA, NEWS -> , CONTEXT_ID -> 2244.0, EXPIR_DATE -> , GEN_VAL4 -> 0.009000000000000001, IRGCOND -> , CAN_TRTFLG -> , ISIN_CODE -> AU000000LCY6, TRD_UNITS -> 4DP )

Should I raise a bug report to the data stream?

Jirapongse

@Carfield Yim

Why are there a lot of 18446744064486179580 in the captured strings?

Those fields are UINT64.

RDNDISPLAY "DISPLAYTEMPLATE" 2 NULL INTEGER 3 UINT64 1
PROD_PERM "PERMISSION" 1 NULL INTEGER 5 UINT64 2
SALTIM_MS "SALTIM MS" 3854 NULL INTEGER 15 UINT64 4
PREV_DISP "PREV DISP TMPLT" 3263 NULL BINARY 3 UINT64 2
RECORDTYPE "RECORDTYPE" 259 NULL INTEGER 3 UINT64 1
QUOTIM_MS "QUOTIM MS" 3855 NULL INTEGER 15 UINT64 4
DDS_DSO_ID "DDS DSO ID" 6401 NULL BINARY 3 UINT64 2

Carfield Yim

https://community.developers.refinitiv.com/discussion/comment/125422#Comment_125422

Not sure, from upstream

Jirapongse

@Carfield Yim

I extracted the raw data of this RIC (LCY.CHA) from 2025-04-21T17:16:12.851194923Z to 2025-04-24T08:55:00.135899254Z. I couldn't see the 18446744064486179580 value in the raw data.

Moreover, the values of the RDNDISPLAY, PROD_PERM, RECORDTYPE, PREV_DISP, and DDS_DSO_ID fields should be constant. Their values must be 117, 4222, 113, 5541, and 4290 respectively.

The values of the QUOTIM_MS and SALTIM_MS fields are:

The problem could be in the API or the application decoding logic. If you are a RDC named user, you can contact the API Support team directly via Contact Premium Support to investigate this issue.

Carfield Yim

https://community.developers.refinitiv.com/discussion/comment/125446#Comment_125446

Thanks a lot for checking, probably just one time error, will raise the request if that happen again. I was just wonder if my code has any mistake