Getting DateTime data from additional data series

[NinjaTrader_Gaby]

Hello,

Thank you for your response.

I do see what you are reporting.

If you want your script to report the November 30th bar as the first bar of December, then you can use the last bar of the session for your custom calculation.

[ChrisR]

Hello,

If you want your script to report the November 30th bar as the first bar of December, then you can use the last bar of the session for your custom calculation.

Gaby,

Its not that I want my script to report that bar, I want it to report the correct bar, the first minute bar of the new month. As I have shown you through a few examples, there are two scenarios where the month changes.

Referenced Code:

Time[0].Month > Time[1].Month && IsFirstBarOfSession

Month Changeover On Weekend:
The referenced code WILL work because bar 0 and bar 1 will have a different month if the first day of the month is Saturday or Sunday. The new session starts Sunday and has a different month than the prior bar.

Month Changeover On Weekday:
The referenced code WILL NOT work because those two conditions will not be true at the same time. When midnight comes around, the first session of the month is already live, so those two conditions cant be true at the same time. At midnight, bar 0 will reflect a different month than bar 1, however midnight isnt the first bar of the session so IsFirstBarOfSession will not be true.

Based on the various examples I have shown you and the information above, how can one account for this to accurately grab the DateTime and Price of the first minute bar of the month?

[NinjaTrader_Gaby]

Hello,

The example script was designed to show it is possible to mark the first bar of the session for a new month with custom logic.

After seeing what is possible, you can design your own custom logic however you would like. If you want to mark the first session that overlaps into a new month that starts in the previous month, you can definitely do this with your own custom logic. As mentioned, you can use the last bar of the session in your custom calculation.

You can use a SessionIterator to get the the start and end times of a session, and you can use Time[0].Month to get the month number.

SessionIterator - https://ninjatrader.com/support/help...oniterator.htm

Using these tools, you can design the logic in a number of ways.

[ChrisR]

Gaby thanks for your time, I'd like to get input from others please.



Is there anyone else on this forum that can assist? I am trying to do the following:

•When the new monthly bar starts, and when viewing from any minute based chart, I'd like to get the session start time and price for that first session of the month.

There are two scenarios when a month change occurs.

Month Changeover On Weekend:

Time[0].Month > Time[1].Month && IsFirstBarOfSession

^^This will work because the new futures session will be on that Sunday (or next day if holiday). Thus the prior bar will have a different month and IsFirstBarOfSession will be true.


Month Changeover On Weekday:
The previous code snippet will not work because the month changes at midnight, thus those two conditions wont be true at the same time. I have tried various ways to get this to work but I keep running into issues. Looking for some assistance here.

[ChrisR]

QuantKey_Bruce

Regarding your recommendation using the additional daily data series, while this grabs the correct price, its updated end of session when that daily bar closes, at least historically. I will look into using BarsRequest, though I have never used this before.

[QuantKey_Bruce]

Since all historical bars e.g. AddDataSeries during State.Historical show up only at the conclusion of that bar, you would need to add a sub-daily bar e.g. a 1 minute bar or something like that, so that you get the open of that first minute of the day at the 9:31 ET close instead of at the 17:00 ET close. This is because SOME bar has to close for you to get the historical open information. You could even make it a 1-tick series to get it at the close of the first tick, although this is super-wasteful of resources and will make it run very slowly and use lots of RAM and CPU for little reason.

Alternatively, you could use a BarsRequest to get what you need and then go back and draw it retrospectively once the monthly or daily bars or whatever have been retrieved. This is a much more complex programming approach, but has the advantage that you do not have to wait for some bar to close to get the information because you are in State.Historical. It has the downside, in addition to complexity, that in order to use the threading model properly you should go back and paint them in retrospect (don't sleep or hold the thread until your data comes in or you will leave NinjaTrader in an unresponsive and possibly crashed state.)

I think you should also ask yourself how important this is - does it really matter, for instance, if you get the open of the MONTH 1 minute into the day? If not, just add a 1-minute series using the approach I described and set the trading hours to RTH.

[ChrisR]

Since all historical bars e.g. AddDataSeries during State.Historical show up only at the conclusion of that bar, you would need to add a sub-daily bar e.g. a 1 minute bar or something like that, so that you get the open of that first minute of the day at the 9:31 ET close instead of at the 17:00 ET close. This is because SOME bar has to close for you to get the historical open information. You could even make it a 1-tick series to get it at the close of the first tick, although this is super-wasteful of resources and will make it run very slowly and use lots of RAM and CPU for little reason.

Alternatively, you could use a BarsRequest to get what you need and then go back and draw it retrospectively once the monthly or daily bars or whatever have been retrieved. This is a much more complex programming approach, but has the advantage that you do not have to wait for some bar to close to get the information because you are in State.Historical. It has the downside, in addition to complexity, that in order to use the threading model properly you should go back and paint them in retrospect (don't sleep or hold the thread until your data comes in or you will leave NinjaTrader in an unresponsive and possibly crashed state.)

I think you should also ask yourself how important this is - does it really matter, for instance, if you get the open of the MONTH 1 minute into the day? If not, just add a 1-minute series using the approach I described and set the trading hours to RTH.

Are you saying to replace the additional data series with a 1m series or add the 1m in addition to the 1D?

if (CurrentBar < 0) return;

if (BarsInProgress == 1)
{
   DateTime DailyBarTime = Time[0];
   DateTime ThisMonth = new DateTime(DailyBarTime.Year, DailyBarTime.Month, 1);
   if (ThisMonth != LastMonth)
   {
      MonthOpenValue = Open[0];
      LastMonth = ThisMonth;
   }
}

if (CurrentBars[0] >= 0 && !double.IsNaN(MonthOpenValue)) MonthlyOpenPlot[0] = MonthOpenValue;

^^If the additional data series was changed from 1D to 1m, this would still only update the price at midnight correct, if the month changes during a weekday and not on the weekend. For example, if December 1st is a Wednesday, than that session started on Tuesday, November 30th at 6pm ET. So when the if (ThisMonth != LastMonth) check occurs, this would be at midnight. That would result in a significant delay (6 hrs) of delay for the price to update. Or am I not understanding your recommendation correct?

[QuantKey_Bruce]

1-minute instead of 1-day, and specifying the trading hours to be RTH for the instrument in question using the appropriate overload of AddDataSeries.

If the bars on the chart consist of ETH bars e.g. they start at 6pm ET the previous day, that does not matter - when the first bar closes on the 2nd series e.g. 1 minute into the RTH, it would know the value historically.

[ChrisR]

1-minute instead of 1-day, and specifying the trading hours to be RTH for the instrument in question using the appropriate overload of AddDataSeries.

If the bars on the chart consist of ETH bars e.g. they start at 6pm ET the previous day, that does not matter - when the first bar closes on the 2nd series e.g. 1 minute into the RTH, it would know the value historically.

Looking at the past two months using your recommendation, looking at a 5min chart:

December to January:
Last bar of December monthly bar = Friday, Dec 29th @ 5pm ET
First bar of January monthly bar = Monday, Jan 1st @ 6:05pm ET
....Price updates and plots correctly


November to December:
Last bar of November monthly bar = Thursday, Nov 30th @ 5pm ET
First bar of December monthly bar = Thursday, Nov 30th @ 6:05pm ET
.....The price updates at 01-Dec @ 12:05am ET, updating 6hrs late past session start, however it is the correct price.

[QuantKey_Bruce]

That's because it's using the timestamp of the bars to determine what month it is. If it's after 6 pm ET, add a day before you calculate the month and you'll have the session date in this case, or you could do something more general using a session iterator and the trading times.

[ChrisR]

That's because it's using the timestamp of the bars to determine what month it is. If it's after 6 pm ET, add a day before you calculate the month and you'll have the session date in this case, or you could do something more general using a session iterator and the trading times.

One of your previous replies gave me an idea. This seems to work across the board. Let me know if you foresee any issue with it.

if (Bars.IsFirstBarOfSession)
{
   mTime = Time[0];
   mPrice = Open[0];
}

if (Time[0].Month != Time[1].Month)
{
   sTime = mTime;
   eTime = Time[0].Date.AddDays(DateTime.DaysInMonth(Time[0].Year, Time[0].Month) - Time[0].Day).AddHours(17);
   sPrice = mPrice;
  
   Draw.Line(this, "Open"+CurrentBar, false, sTime, sPrice, eTime, sPrice, Brushes.White, DashStyleHelper.Dash, 1, true);
}

^essentially just cataloging every session start time and start price separate from the month check condition, than grabbing the ones when a month changes and using those values to create the start anchor point. Adding the remainder days in the month to create the end time anchor.

[QuantKey_Bruce]

Whatever gets you where you need to be. If it's working I would say that is acceptable.

[ChrisR]

Whatever gets you where you need to be. If it's working I would say that is acceptable.

Thanks for the assistance.

[ChrisR]

I have not tested but i think this could work:

protected override void OnStateChange()
{
if (State == State.Configure)
{
AddDataSeries(BarsPeriodType.Day, 1);
}
}

// OnBarUpdate method
protected override void OnBarUpdate()
{
// Check if it's the first bar of the session and a new month
if (Bars.FirstBarOfSession && Time[0].Day != Time[1].Day)
{
// Print a message to the output window
Print("First bar of a new month!");
}
}​

This would not work because Bars.FirstBarOfSession && Time[0].Day != Time[1].Day would be true at the same time only if the month changed on a weekend. If the month changed on a weekday, those two conditions would never be true at the same time because the Day integer changes at midnight, which is not the first bar of the session.

The example I provided in post #26 does however work and accounts for both a change in month on a weekend and weekday.