Repository navigation
intraday-cap rollover uses calendar midnight, not session open (overnight-session instruments) #26
Description
Tracks the deferred portions of #19 after #25 landed the injection path.
#25 delivered: strategy_set_syminfo_timezone / _session (feed session.ismarket / time(session)), and strategy_set_syminfo_metadata (double map; un-injected fundamental fields read na). Harness forwards runtime_overrides.{timezone,session,syminfo_metadata}.
Remaining:
-
Fundamentals data source. The metadata path exists but no feed populates it —
shares_outstanding_*,recommendations_*,target_price_*readnauntil ametadata.json-style source is wired into the corpus/serving harness. -
Exchange-tz validation for intraday gates (US equities). The intraday day-rollover gates deliberately stay on
chart_timezone_(probe-97: TV matched chart tz for crypto-on-UTC+8-chart; switching tosyminfo_.timezoneregresses it). For real-session instruments the serving layer pinschart_timezone_to the exchange tz. No checked-in corpus probe exercises chart_tz ≠ exchange_tz, so this is validated as a no-op on UTC data only. Needs a real RTHAmerica/New_YorkUS-equity intraday-cap probe with a captured TV run before shipping feat(engine): support symbol metadata and exchange timezone boundaries #19 semantics to US-stock traders. -
Session-open intraday rollover (layer 2). Even on exchange tz, the gate day-key is calendar midnight, not session open. Overnight-session instruments (futures/FX) roll their trading day at session open; route the gate day-key through
pine_time_tradingday. (Original analysis in the feat(engine): support symbol metadata and exchange timezone boundaries #19 thread.)
Activity
docs(probes): design validation probes for input.source / color / sym…
feat: input.source series helper + syminfo tz/session/metadata inject…
luisleo526 commentedon May 31, 2026
Re-scoping — two of the three items are no longer open:
1. Fundamentals data source — NOT an engine issue (closing out).
The engine's responsibility ends at the runtime injection path
(
strategy_set_syminfo_metadata);syminfo.*fundamentals readnauntil avalue is fed. Sourcing/populating those values is the data layer's job, not the
compute engine's. Since the values can be imported at runtime, there is nothing
left for the engine to do here.
2. Exchange-tz validation — RESOLVED.
The SPX intraday-cap special probe (
corpus/special-validation/, SP:SPX 5m,chart tz UTC+8) exercises exactly the discriminating case: a real US-equity RTH
session whose chart-local midnight (00:00 Asia/Taipei = 16:00 UTC) falls
mid-session, where the cap day-rollover tz choice matters. Result:
920/920 trades matched, 0% entry/exit/PnL delta with the gates on
chart_timezone_. So TradingView rolls the intraday cap on the charttimezone (not exchange tz) for US equities too — confirming the gate design and
generalizing the probe-97 (crypto) finding. Exchange-tz alignment for US stocks
is achieved by the serving layer pinning
chart_timezone_to the exchange tz;no engine change needed.
3. Session-open intraday rollover (layer 2) — remains.
The only genuine engine item left: for overnight-session instruments
(futures/FX) the cap day-key is calendar midnight, not session open. Route the
gate day-key through
pine_time_tradingdaywhen a non-24x7 session is set.Niche; not blocking US-equity/crypto.
Narrowing this issue to item 3.
[-]syminfo follow-ups: fundamentals data source, exchange-tz validation, session-open intraday rollover[/-][+]intraday-cap rollover uses calendar midnight, not session open (overnight-session instruments)[/+]luisleo526 commentedon May 31, 2026
Closing as not-a-bug.
The remaining item (session-open intraday-cap rollover for overnight-session
instruments) is contradicted by the evidence. The SPX special probe
(
corpus/special-validation/, SP:SPX 5m, chart tz UTC+8) puts chart-calendarmidnight (00:00 Asia/Taipei = 16:00 UTC = 12:00 ET) mid-session, and TV
reset the intraday cap there — matching the engine's calendar-day-in-chart-tz
key bit-for-bit (920/920, 0% delta). So TradingView rolls the intraday cap on
chart-calendar-midnight, not session open, even when that splits a real
trading session.
Routing the gate day-key through
pine_time_tradingday(session-open rollover)would therefore make overnight-session instruments diverge from TV, not
converge. No evidence TV ever uses session-open rollover; the current behavior
is correct for every case tested (crypto probe-97 + US-equity SPX).
If an overnight-futures case ever shows a real divergence, reopen with a
captured ES (or similar) TV run as evidence and we'll revisit.
h1rot commentedon Jul 30, 2026
Following up on the invitation here to reopen with a captured ES TradingView run as evidence — I filed #141 with one.
Two notes on scope, so you can decide whether it belongs under this issue or stands on its own:
strategy.close(guarded byif bar_index < 0) changes 60 position sizes and moves Net PnL by 182.00 on the same ES data, becausescript_has_strategy_close_is an AST scan that gates the deferred-flip carry. That reproduces entirely inside PineForge.strategy.closechanges backtest results (60 trades, PnL 182.00) viascript_has_strategy_close_#141 as supporting evidence for which behaviour is faithful, but I am upfront there that none of my three engine runs share data (TV isCME_MINI:ES1!15-minute 2025-09 to 2026-07; PineForge and PyneCore are Databento ES continuous 1-minute 2025 Q1), and that my account cannot reach TradingView ES 1-minute back to 2025 Q1.Happy to move it here instead if you would rather keep overnight-futures divergences in one place.
Discard dust-sized margin-call restore requirements before lot quanti…