Posted: Nov 25, 2013 @ 04:54 PM             Msg. 1 of 19

When I make the following request:

OECAPI()->RequestHistory(con,dr.GetDate().m_dt,dt.m_dt);
- con is a valid contract point for RLM-MZ3
- 1st m_dt == 41600.041666666664 (11/22/13 1AM)
- 2nd m_dt == 41603.904861111114 (11/25/13 21:43)

I receive back these bars:

11/22/2013 1118.7 1125.5 1116.3 1123.8 65605 0
11/24/2013 1124.7 1128.9 1123.7 1128.1 526 0
11/25/2013 1128.6 1128.6 1122.0 1125.8 49590 0

Note the 11/24 (Sunday) bar. No other contract, including mini's, has a bar with a Sunday timestamp when we perform this request with those DateTimes.

We've been watching this for over a month. At close today (Monday at 4PM MT), I perform this same request again, with the same contract pointer and DateTimes, but the Sunday 11/24 bar is no longer returned to us in the OnBarsReceived callback.

We do not expect to ever receive a futures daily bar with a Sunday DateTime.

Could you please inform us about how to resolve this issue?

Thanks,

---

CHW

Posted: Dec 04, 2013 @ 04:16 PM             Msg. 2 of 19

This is occurred this Monday 12/2/13 as well. Let me know if I can assist you with troubleshooting this bug.

---

CHW

Posted: Dec 05, 2013 @ 11:12 AM             Msg. 3 of 19

What timestamp do you check - opening or closing?

---

Victor Vins
Lead Software Developer

Posted: Dec 11, 2013 @ 10:43 PM             Msg. 4 of 19

We use OECAPICOM::IBarPtr bar->Timestamp.

Each of those historical daily bars had a 1:00AM time after the date when I converted the bar->Timestamp to a COleDateTime object.

I didn't get a chance to check on this last Monday. Given all the recent work and success with the new order engine, I'll get back in touch with this post next Monday with an update on whether the issue is still continuing.

---

CHW
Edited by CWeber984 on Dec 23, 2013 at 14:18:52
Edited by CWeber984 on Dec 23, 2013 at 14:19:09

Posted: Dec 16, 2013 @ 02:19 PM             Msg. 5 of 19

The same issue is occurring today, where we get separate Sunday and Monday historical bars:

12/13/2013 1:00AM 1101.6 1110.6 1099.3 1104.9 31568
12/15/2013 1:00AM 1105.0 1106.9 1104.6 1106.7 104
12/16/2013 1:00AM 1106.5 1119.9 1095.7 1118.0 7279

If you want the Timestamp pure value before converting to a COleDateTime:

<Unix time, receipt of On BarsReceived callback for history request, symbol, ColeDatetime representation of Bar->timestamp, Bar->Timestamp>
1387221156 RLM-MZ3:12/13/2013 1:00:00 AM: 41621.041667: 31568
1387221156 RLM-MZ3:12/15/2013 1:00:00 AM: 41623.041667: 104
1387221156 RLM-MZ3:12/16/2013 1:00:00 AM: 41624.041667: 8794

Let me know if I can assist you further in diagnosing this issue.

---

CHW

Posted: Dec 27, 2013 @ 06:59 PM             Msg. 6 of 19

Here's more information regarding the strange RLM-MH4 Sunday bar obtained during last Monday's session. This data capture provides both the opening and closing timestamp:

[bar->Timestamp as COleDateTime]:[bar->CloseTimestamp as COleDateTime]:[bar->Open]:[bar->High]:[bar->Low]:[bar->Close]:[bar->Volume]

-12/20/2013 1:00:00 AM:12/20/2013
11:00:00 PM:1122.1:1144.7:1121.6:1144.2:81650
-12/22/2013 1:00:00 AM:12/22/2013
11:00:00 PM:1144:1146.8:1144:1146.8:211
-12/23/2013 1:00:00 AM:12/23/2013
11:00:00 PM:1146.9:1154.6:1145.9:1152.9:45647

This coming Monday I will provide more data about the DateTime args in this request:

OECAPI()->RequestHistory(valid contract ptr, last data record's m_dt, current time's m_dt);

Let me know if I can provide more data to you regarding the historical data request and the values of the bars received in OnBarsReceived.

Thanks,

---

CHW

Posted: Dec 31, 2013 @ 12:46 PM             Msg. 7 of 19

I did some more thorough digging using the OEC Cpp Sample project instead of our own code base.

In CCppCOMSampleDlg::OnBnClickedHistory(), I requested RLM-MH4 history as follows:

COleDateTime from(2013, 12, 25, 0, 0, 0); //12/25/2013(41633.0000000)
COleDateTime to(2014, 1, 1, 0, 0, 0); //1/1/2014(41640.0000000)
OECAPI()->RequestHistory(OECAPI()->Contracts->Item((LPCSTR)dlg.m_SelectedSymbol),from.m_dt, to.m_dt);

In CCppCOMSampleDlg::OnBarsReceived(...), here's the Sunday and Monday bars:

Open Time, Close Time, Open, High, Low, Close, Volume
12/29/2013 1:00:00 AM, 12/29/2013 11:00:00 PM, 1157.1999512, 1158.1999512, 1157.0999756, 1157.0999756, 187
12/30/2013 1:00:00 AM, 12/30/2013 11:00:00 PM, 1157.0999756, 1161.0999756, 1155.5999756, 1157.3000488, 44019

Importantly:
- 12/29/2013 1:00:00 AM GMT == 12/28/2013 20:00:00 US ET, the timezone for ICE. In other words, what I'm referring to as the Sunday bar could actually be referred to as a Saturday bar according to our time zone (US MT, GMT - 7).
- The two bars above are presented as merged into the Monday bar in the OEC Trader Demo.

According to the specs for RLM-M:
https://www.theice.com/productguide/ProductSpec.shtml;jsessionid=3CBCB9608116CBB19FE1DDC644F8BFC6?specId=86
trading for the Monday session begins on Sunday evening in the U.S. at 6:00 PM ET.

Its possible that the Sunday bar is accommodating the 2 hours extra for the Sunday open vs. regular open time.

I hope the info above assists you in determining why the RLM-M historical request for daily bars gives 2 bars for the session that opens on Sunday 6PM ET and closes on Monday at 6PM ET.

This is the only commodity we've found that handles the early Sunday open by giving back 2 bars instead of one. I'm interested in what you think about this issue, and what you might recommend as next steps for us as one of your api clients.

Thanks,
Edited by CWeber984 on Dec 31, 2013 at 12:57:17

Posted: Jan 13, 2014 @ 02:08 PM             Msg. 8 of 19

As usual we get a Sunday bar, as if there had been a session that opened on Saturday. As discussed in emails, this occurs in the Cpp sample code as well. Our tests continue to show that this is the only symbol for all symbols and contracts offered that gives this Sunday bar:

O/H/L/C/Vol/OI
1/12/2014 1161.3 1162.0 1160.0 1160.7 220 0
1/13/2014 1160.3 1161.4 1149.5 1150.3 63783 0

Thanks for looking into it!

---

CHW

Posted: Jan 16, 2014 @ 08:52 AM             Msg. 9 of 19

We found the issue. The fix will be installed to API environment this Friday.

---

Vitaliy Pfau

Posted: Mar 10, 2014 @ 04:33 PM             Msg. 10 of 19

Is this fix going to be posted to the COM api at some point? Do you have any timetable for that?

---

CHW

Posted: Mar 10, 2014 @ 04:40 PM             Msg. 11 of 19

During this week.

---

Victor Vins
Lead Software Developer

Posted: Mar 10, 2014 @ 04:41 PM             Msg. 12 of 19

Thanks for your quick reply. We appreciate your support.

---

CHW

Posted: Mar 24, 2014 @ 07:35 PM             Msg. 13 of 19

Added the newest COM api today, 3.24.14. It's API.dll is versioned at 3.5.12.0.

RLM-MM4 is now the front month contract for RLM-M.

We continue to get the same extra Sunday session bar that was reported in this thread's first post. It continues to be odd that the Sunday session is split into two bars, and that this extra Sunday bar disappears after the close of the Monday session.

Any thoughts on what we might be doing wrong?

---

CHW

Posted: Mar 31, 2014 @ 05:45 PM             Msg. 14 of 19

During the Monday session, RLM-M gets a Sunday bar returned through the most recent COM Cpp sample as well as the regular Monday session bar. The Sunday bar disappears at market close of the Monday session.

API OEC COM 3.5 exe Cpp Sample history request:

OECAPI()->RequestBars(con, 41705.0, nowUTC.m_dt, OECAPICOM::SubscriptionType_Bar, 1440);

returns this for RLM-MM4 contract (time/O/H/L/C):

3/30/2014, 1150.0000, 1153.6000, 1150.0000, 1153.5000
3/31/2014, 1153.2000, 1171.7000, 1150.3000, 1166.4000

Date/O/H/L/C

OEC Trader: 2014/03/31 1150 1171.7 1150 1166.4
OEC Trader Demo: 2014/03/31 1150 1171.7 1150 1166.4


You can see that the two bars returned in the Cpp history request have been merged into one bar in OEC Trader and Trader Demo. Unfortunately, we can't also merge these two bars, because their bar->Timestamp field returns different day results.

As always, it makes no sense that there is a Sunday daily historical bar given, as there is no Sunday session for RLM-M.

Thanks,

---

CHW
Edited by CWeber984 on Apr 1, 2014 at 16:22:17

Posted: Apr 01, 2014 @ 06:37 PM             Msg. 15 of 19

The issue with RLM-M is on server-side and related to daylight savings time change recently. Development of solution for this issue is in progress. You will not need to install a new version of API as soon as we roll the bugfix out.

---

Victor Vins
Lead Software Developer

Posted: Apr 02, 2014 @ 03:38 PM             Msg. 16 of 19

Thanks. I'll keep my eye on it and test the fix when it goes out. If you post when the fix is in it will be helpful. We coded a workaround hack and so hide this issue from our users (and myself); it will be terrific to remove that hack. I respect that your dev team has a million things to do and so don't mind if you all forget to post when the fix is in.

---

CHW

Posted: Apr 21, 2014 @ 05:00 PM             Msg. 17 of 19

Discovered some more symbols/contracts with a strange Sunday bar in the history request callback. The Sunday bar disappears if the history request is made after market close for the Monday session.
1) RS2M Canola Oil
2) NSEAM Oil, Brent Crude

Thanks,

---

CHW