using rdp/eikon API with python
for instruments like ESU1, SPX.U or STXE or SPX options.
For a deeper look into our Eikon Data API, look into:
Overview | Quickstart | Documentation | Downloads | Tutorials | Articles
39.2k
●75 ●11 ●27
You can get the timezone of the exchange using TR.MASOperatingTZ field, e.g.
ek.get_data('ESU1','TR.MASOperatingTZ')
And then you can use this timezone in say pytz library to get offset from GMT for any given date or to convert the timestamps for timeseries from GMT to the timezone of the exchange, e.g.
ric = 'ESc1' df, err = ek.get_data(ric,'TR.MASOperatingTZ') tz_str = df.iloc[0,1] df = ek.get_timeseries(ric, interval='tick', count=100) df.index = df.index.tz_localize(pytz.utc).tz_convert(tz_str)
1
●2 ●1 ●4
although that works for some, it doesn't work for all. do you not have a way of knowing for everything?
here follows a not-at-all uncommon list of tickers..... look how poor the population is.
Instrument MAS Operating TimeZone
0 /STXEU1 Europe/Berlin
1 /STXEZ1 <NA>
2 /STXEH2 <NA>
3 /STXEM2 <NA>
4 /STXEU2 <NA>
5 /STXEZ2 <NA>
6 /STXEH3 <NA>
7 /STXEM3 <NA>
8 /FVSQ1 <NA>
9 /FVSU1 <NA>
10 /FVSV1 <NA>
11 /FVSX1 <NA>
12 /FVSZ1 <NA>
13 /FVSF2 <NA>
14 /FVSG2 <NA>
15 /FVSH2 <NA>
16 /NQU1 America/Chicago
17 /NQZ1 America/Chicago
18 /NQH2 America/Chicago
19 /NQM2 America/Chicago
20 /NQU2 America/Chicago
21 0#SET: <NA>
22 /ESU1 America/Chicago
23 /ESZ1 America/Chicago
24 /ESH2 America/Chicago
25 /ESM2 America/Chicago
26 /ESU2 America/Chicago
27 /ESZ2 America/Chicago
28 /ESH3 America/Chicago
29 /ESM3 <NA>
30 /ESU3 <NA>
31 /ESZ3 <NA>
32 /ESZ24 <NA>
33 /ESZ25 <NA>
34 /VX32Q1 <NA>
35 /VXQ1 <NA>
36 /VX34Q1 <NA>
37 /VX35U1 <NA>
38 /VX36U1 <NA>
39 /VXU1 <NA>
40 /VX38U1 <NA>
41 /VXV1 <NA>
42 /VXX1 <NA>
43 /VXZ1 <NA>
44 /VXF2 <NA>
45 /VXG2 <NA>
46 /VXH2 <NA>
47 /VXJ2 <NA>
48 .SPX <NA>
49 .SET <NA>
50 .VIX <NA>
51 .NDX <NA>
52 .XNDX <NA>
53 .V2TX <NA>
54 .STOXX50E <NA>
39.2k
●75 ●11 ●27
I'm not surprised this field is not populated for indices, as indices are not exchange traded products. But for futures this field should be populated consistently. I raised a case with Refinitiv Support to investigate why the data is missing. Refinitiv Helpdesk will escalate the issue to the relevant content team and will keep you informed on the results of the investigation. For your reference the case number is 10168005.
so as I've mentioned to others at Refinitiv, your other APIs (like Tick History or whatever it's now branded as) have precisely this information for precisely those securities.
can you not suppose a workaround? it's starting to really get annoying now--it's been weeks with many touch points at Refinitiv for something that really shouldn't even exist as a problem in the first case.
Short of manually creating your own map between exchange IDs and timezones, I don't see any workaround. The use case of converting standardized GMT timestamps in timeseries to the timezone of the exchange is rather uncommon.
The case 10168005 is still being worked on, and the problem with missing values for TR.MASOperatingTZ field for future RICs is being investigated. I appreciate this is taking a while. While I don't have an ETA for when the issue will be resolved, I assure you that it is being actively worked on.
1.7k
●2 ●4 ●7
Hi @opsp ,
I'd like to inform you that case 10168005 has been resolved. Even though the financial indices (like .SPX ) aren't supported, other RICs should work. You may find an example below (the RICs list was taken from your comment above)
