The open-source engine runs on the data you give it. History depth, delay and coverage are those of your source, not of the engine.
Data sources
Yahoo’s history has survivorship bias: delisted stocks aren’t there. A strategy that looks good on today’s survivors may not have been tradeable at the time.
Bundles
Bars are ingested into a named bundle, stored as Delta Lake tables under ~/.ziplime/data, and keyed by the sid of each instrument in the asset database. That is why instruments come first:
-f, --frequency sets the bar interval of the bundle: 1m, 5m, 15m, 30m, 1h, 1d, and others.--merge adds to an existing bundle instead of replacing it.--forward-fill (on by default) fills sessions an instrument didn’t trade with its previous close.- A ticker that isn’t unique must be written
TICKER@MIC.
Each ingest creates a new bundle version; ziplime run --bundle-version picks one, and ziplime clean removes old ones.
Timeframes
A run’s emission rate — how often handle_data is called — can be anything from one minute to one day: 1 minute, 5, 15, an hour, a day.
- A minute bundle can feed a slower run: in the Python API,
load_bundle(..., frequency=..., aggregations=[...]) aggregates bars to the requested frequency (see examples/run_simulation_daily_yahoo_finance.py).
- Intraday vendor bars are placed on the simulation clock so no bar leaks into the one before it.
time_rules in schedule_function work at any intraday rate.data.history(frequency=...) reads a window at a different interval from the emission rate.
Point in time
Datasets that describe the past with a delay — filings, fundamentals, disclosures — are windowed by the date a row became public, not by the period it describes. A strategy on bar t sees only what was published by t.
The engine is not intended for strategies whose outcome depends on sub-second timing, such as high-frequency trading or latency arbitrage. See Limitations.