Eikon Scripting API: issues with timeseries
Hi all,
The Eikon API 'get_timeseries' function shows unexpected behavior. The 'start_date' is not respected in the following code:
market = [ '.BADI','FXSYSAL=NPX','ENOFBLQH8','ENOFBLYZ8','ENOFBLYZ9','F1BYF8','F1BYF9','F1PQV7','F1PYF8','F1PYF9','ATWQU7','ATWQZ7','ATWYZ8','ATWYZ9','CFI2Z7','CFI2H8','CFI2Z8','CFI2Z9','LCOc1','LCOc2','LCOc3','.OSEBX','.GDAXI','.SSEC','.AXJO','.FTSEE','EUR=X','NOK=X','GBP=X','/.DXY','/.BADI','SKMELYH8','SKMELYH9',]
df = eikon.get_timeseries(market,
fields=["Close"], start_date = "2016-03-01",
interval="daily")
df
Furthermore, there is no error message when hitting the 3,000 output limit. So the output (of 7 instruments * 472 rows = 3302) results looks like this:
While the output of 5 instruments * 472 rows = 2460 looks like this:
Can we please get error message instead of populating the output with NaNs?
Thanks for your help!
Best Answer
-
The problem as I see it is the shared 3K rows limit, which is the reason for both the timeseries returned not stretching back to 01-Mar-2016 when you send 33 RICs in a single request, and for some rows for some instruments being returned as NaN when 3K divided by the number of RICs does not result in an integer.
The 3K limit issue has already been raised here and reported to development and product management:
https://community.developers.refinitiv.com/questions/6355/bug-in-get-timeseries.html0
Answers
-
I guess that the date is ignored, because you are hitting the limit. Here is a handy function to check if your are okay:
from datetime import date
from numpy import busday_count
def number_of_points(instruments, start_date, end_date=0):
days = busday_count(start_date, date.today() if end_date==0 else end_date)
return len(instruments)*daysBased on your request, the number of points is 11583 instead of the 3000 limit, as the number of instruments on your market list is 33.
0 -
Thanks Zhenya. I understand it is because of the 3000 limit, but this makes it error prone, so we would like to see an error message instead.
0 -
Thanks Alex. That would mean that when the 3K limit issue has been fixed, the issue with NaNs wouldn't be applicable anymore, right?
0 -
Right. I'm not sure what the plan is for addressing this issue, but personally I would consider anything short of increasing the limit to at least 50K rows per RIC (not shared by all RICs in the request) to be unsatisfactory. Any solution that does not allow one to retrieve at least 50K rows for each RIC in the request would be deficient compared to capabilities available through legacy Eikon APIs.
0 -
So the second problem will persist when we keep a shared limit, but would just be moved... Any way we can produce warning messages from server side?
0 -
Correct. As long as there's a shared limit the second problem will persist.
0 -
Could you help explain the means for 3000 points limitation.
Is it means that we can't get data more than 3000 at one time ?
If store data to excel, it's limit to get 3000 cell data at a time?
0 -
The response to any single get_timeseries request for interday timeseries interval is limited to 3K rows. That is you will never get more than 3K rows of timeseries data when you execute get_timeseries method no matter what parameters you use. If get_timeseries uses a list of RICs, the 3K limit is shared. I.e. if you pass 10 RICs to get_timeseries method the total response is limited to 3K rows or 300 rows per RIC.
0 -
This is a very unfortunate limit of the timeseries Web service behind Eikon Data API. RHistory function of Eikon Excel or Eikon .NET API use different Web service to retrieve timeseries, which is not subject to this limit. The most unfortunate part is that the limit is shared between RICs in the same request. Hopefully one day the limits will be improved. Until then you can execute get_timeseries requests for one RIC at a time, although in this case you'll be subject to another limit: the throttle allowing the requests to be sent with a max frequency of 3 requests per second.
1 -
Would it be possible to produce some error messages until this has been solved? I would say the confusion is more of an issue than the actual limit itself.
0 -
@Alex Putkov. Is this 3000 limit going to remain when the API is out of beta?
1
Categories
- All Categories
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 60 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛