dayofweek(time, "America/Chicago") evaluates one day forward vs TradingView reference

[Zombajo]

Summary

In PyneCore v6.4.5, dayofweek(time, "America/Chicago") returns a day value that is one day ahead of TradingView's evaluation for the same bar timestamps. This affects strategies that use day-of-week filtering against a non-UTC timezone — long entries are taken on the wrong weekday relative to the strategy's intent and against TradingView's reference output.

Empirical evidence

Symmetric same-week bars from a CME_MINI:NQ1! 10m strategy with a "no Thursday Chicago" filter (g17):

• Oct 29 2025 (Wed CDT in Chicago): TV accepts entry (g17 = pass). PyneCore rejects (computes day as Thursday).
• Oct 30 2025 (Thu CDT in Chicago): TV rejects entry (g17 = fail). PyneCore accepts (computes day as Wednesday).

The pattern is consistent across the full 2025 Oct → 2026 Apr empirical overlap window. Per-trade match between PyneCore and TV strategy tester on this strategy is 1/25 (~4%) primarily due to this divergence.

Reproduction

Minimal Pine source:

//@version=6
indicator("dow_chicago_repro", overlay=false)
dow_chicago = dayofweek(time, "America/Chicago")
plot(dow_chicago, "DoW Chicago")

Run on CME_MINI:NQ1! 10m (or any instrument with intraday bars during US trading sessions). For any bar Oct 29 2025 (Wed CDT), TV reports dayofweek == 4 (Wednesday); PyneCore reports dayofweek == 5 (Thursday). Symmetric for Oct 30.

Suspected cause

Sign error or off-by-one in the timezone offset applied during dayofweek evaluation. The bar timestamp itself is correct in UTC; the conversion to America/Chicago for the dayofweek computation appears to apply the offset in the wrong direction, producing a "next-day" result.

Impact

Any strategy that uses dayofweek(time, "America/Chicago") or similar non-UTC timezone in a day-of-week filter will produce different trade sets in PyneCore vs TradingView. This affects:

• Per-trade entry alignment for backtest reconciliation
• Aggregate PnL when entries are filtered by weekday
• Any strategy claim built on PyneCore output that uses tz-aware dayofweek

Environment

• PyneCore version: pynesys-pynecore 6.4.5
• Python: 3.13.7
• OS: Windows 11

Related

• Percent commission underreported on entry fills — sizing path uses correct formula, execution path uses buggy formula #48 (percent-commission, fixed in v6.4.5)
• barstate.isconfirmed returns wrong value inside request.security subprocess #49 (closed as not-a-bug)
• Strategy PnL output for futures contracts is in points, not USD — pointvalue not applied #50 (futures pointvalue, OPEN — independently confirmed still present in v6.4.5)
• strategy.commission.cash_per_contract charges only entry, not exit #51 (cash_per_contract, fixed pending release)
• v6.4.5 percent-of-equity sizing still produces large per-trade PnL drift vs TradingView #52 (percent-of-equity / basecurrency, fixed pending release)
• AST transformer rewrites barstate.isconfirmed as a call, but historical-mode subprocess assigns it as a literal True → TypeError: 'bool' object is not callable #53 (barstate AST-vs-subprocess, fixed on main pending release)