Closed jcity closed 1 year ago
Related questions that I haven't been able to answer from searching the issues and documentation:
state.time
(the first datetime printed) different from bar['time']
?bar
parameter Let me know if I should open a different issues for these questions.
Thanks!
These are good questions I appreciate the careful testing.
I think that most of what you're seeing is how alpaca returns data back to the user and just how we're forced to handle sparse bars. Your original question is about the duplicate bar, in this case you can see its complaining that no data was found. The engine sends a bar event callback anyway with a user warning like you're seeing, so it's recognizing that it has no data for that range and just sends the most recent data. It might look weird because the warning is after the strategy print but this is fairly common when rapidly mixing stderr
and stdout
outputs.
If you chart bar data you can see the sparsity issue in pre-market and after-market hours:
The only offered guarantee of the state.time
variable with bar events is that state.time
will be at most one resolution size ahead of the bar time which is the case here.
The bar['time']
attribute is the bar open time, the bar close time is bar['time'] + resolution
.
There might be some subtle timing bugs lurking but with just a quick look over it seems to be expected behavior.
We use this bit of code to filter on our end when doing stock bar events:
timestamp = datetime.datetime.fromtimestamp(bar['time']).astimezone(tz=timezone.utc)
if timestamp.weekday() >= 5 or timestamp.time() < START or timestamp.time() > END:
return
where
START = datetime.time(13, 30)
END = datetime.time(20, 00)
Description
Getting this warning from the backtesting engine using the
bar_event
callback.settings.json
backtest.json (if applicable)
Note: I edited the
cache_location
hereError (if applicable)
Platform Info
Additional context
Repro code:
Output:
Note the (what looks like) a duplicate bar on the last hour of the day