New behavior: Resampling on End of Session

backtrader

There is a commit in the development branch which works on getting the resampled bar pushed out at sessionend time if the timeframe is TimeFrame.Daily.

This should not break any existing behavior.

Commit 9dfce5a2286e8b9c68b55aaf705c3f3ea9471f58

A sample using some recent intraday data.

First without the new behavior

Len,83,Dt,2017-01-05 21:50:00,Len0,83,Len1,0,Dt0,2017-01-05 21:50:00,Close0,3310.0,3311.0,3308.0,3309.0,Dt1,0001-01-01 00:00:00,Close1,nan
Len,84,Dt,2017-01-05 22:00:00,Len0,84,Len1,0,Dt0,2017-01-05 22:00:00,Close0,3308.0,3310.0,3305.0,3307.0,Dt1,0001-01-01 00:00:00,Close1,nan
Len,85,Dt,2017-01-05 22:00:00,Len0,84,Len1,1,Dt0,2017-01-05 22:00:00,Close0,3308.0,3310.0,3305.0,3307.0,Dt1,2017-01-05 22:00:00,Close1,3298.0,3315.0,3290.0,3307.0
Len,86,Dt,2017-01-06 08:10:00,Len0,85,Len1,1,Dt0,2017-01-06 08:10:00,Close0,3305.0,3305.0,3300.0,3302.0,Dt1,2017-01-05 22:00:00,Close1,3298.0,3315.0,3290.0,3307.0

The following happens:

At data point 83 the time is 21:50 for dt0 which is intraday 10-minutes and dt1 which is the resampled version to 1-day is not yet delivering any data.
At 84 dt0 reaches the end-of-session limit which is 22:00, but dt1 still doesn't deliver
At 85, dt0 has paused (its length remains at 84) giving a chance to dt1 to deliver the fully resampled bar.
From there on the story is repeated each day. This is ok for offline backtesting, because the backtrader engine pauses the minor timeframe, to keep it synchronized with the larger timeframe which has said it wants to deliver.
But: it can do so because it recognizes that at data point 86, dt0 will deliver a bar which has a timestamp already into the next day/session.

Obviously when dealing with live data, the pausing happens: next day

There seems to be a use case for people who want to do something right at the end of the session and hence the need for the resampled bar to be delivered as soon as possible.

New behavior (not yet part of the main release)

Len,83,Dt,2017-01-05 21:50:00,Len0,83,Len1,0,Dt0,2017-01-05 21:50:00,Close0,3310.0,3311.0,3308.0,3309.0,Dt1,0001-01-01 00:00:00,Close1,nan
Len,84,Dt,2017-01-05 22:00:00,Len0,84,Len1,1,Dt0,2017-01-05 22:00:00,Close0,3308.0,3310.0,3305.0,3307.0,Dt1,2017-01-05 22:00:00,Close1,3298.0,3315.0,3290.0,3307.0
Len,85,Dt,2017-01-06 08:10:00,Len0,85,Len1,1,Dt0,2017-01-06 08:10:00,Close0,3305.0,3305.0,3300.0,3302.0,Dt1,2017-01-05 22:00:00,Close1,3298.0,3315.0,3290.0,3307.0
Len,86,Dt,2017-01-06 08:20:00,Len0,86,Len1,1,Dt0,2017-01-06 08:20:00,Close0,3302.0,3304.0,3301.0,3303.0,Dt1,2017-01-05 22:00:00,Close1,3298.0,3315.0,3290.0,3307.0

And now:

At 84, both the 10-minutes and 1-day data feeds produce the bar for 22:00.
The length of the system (84) and that of the minor timeframe (84) remain synchronized because it's not being paused
At point 85, the minor timeframe has moved into the next day/session (08:10) whilst the only available resampled value from the previous day is still offered.

Note: Should you need the larger timeframe to deliver the updated daily bar, you are then looking for the replaydata functionality in cerebro and not for resampledata