Posted: Jul 10, 2013 @ 09:06 PM             Msg. 1 of 3

We know that range bars can be generated multiple times per second.

For example, GCLQ3 on 7/7/13 at 4:00:01 PM has 7 bars generated. From the OnBarsReceived callback, here are the (OECAPICOM::IBarPtr) bar->Timestamp values (in GMT):

7/7/2013 10:00:01 PM: 41462.91667824074100000000
7/7/2013 10:00:01 PM: 41462.91667824074100000000
7/7/2013 10:00:01 PM: 41462.91667824074100000000
7/7/2013 10:00:01 PM: 41462.91667824074100000000
7/7/2013 10:00:01 PM: 41462.91667824074100000000
7/7/2013 10:00:01 PM: 41462.91667824074100000000
7/7/2013 10:00:01 PM: 41462.91667824074100000000

The reason why I say the range bar timestamps are lossy is because it is impossible that these bars were generated at the very same time; the precision of the timestamp stops at the double's 1 second equivalent.

I am using the C++ COM api. Would it be possible to get a greater precision for the timestamp? This would greatly assist us to:
- resolve the proper ordering of these bars if needed
- facilitate the use of, say, a std::map whose key was the timestamp
- unfortunately, a std::multimap would not preserve the ordering

I am now checking whether the C# .NET api gives greater resolution for the bar->Timestamp, as it is not a double, but a DateTime instance.

Thanks much,

---

CHW

Posted: Jul 16, 2013 @ 09:49 AM             Msg. 2 of 3

We are using "ticks" to distinguish bars with identical timestamps. Unfortunately, OLE Automation date/time cannot provide such precision. So, we introduced two properties to COM API: IBar.TimestampLong and IBar.CloseTimestampLong that represent .NET DateTime.Ticks value. This version of COM API will be released at the end of this week.

---

Victor Vins
Lead Software Developer

Posted: Jul 18, 2013 @ 03:29 PM             Msg. 3 of 3

Thanks sounds like a principled solution. Thanks for your support!

---

CHW