QuantConnect/Lean · error · RegressionTestException

The time zone of security {firstCustomSecurity} should be {T

Error message

The time zone of security {firstCustomSecurity} should be {TimeZones.Utc}, but it was {firstCustomSecurity.Exchange.TimeZone}

What it means

Asserts that AddData<T>(symbol, resolution, exchangeTimeZone, fillForward) honored the third argument as the exchange time zone. After registering ExampleCustomData on an FXCM EURUSD symbol with TimeZones.Utc, the Security.Exchange.TimeZone must equal Utc. A mismatch means AddData ignored or overrode the supplied time-zone parameter.

Source

Thrown at Algorithm.CSharp/CustomDataWorksWithDifferentExchangesRegressionAlgorithm.cs:38

namespace QuantConnect.Algorithm.CSharp
{
    /// <summary>
    /// Regression algorithm to assert we can have custom data subscriptions with different exchanges
    /// </summary>
    public class CustomDataWorksWithDifferentExchangesRegressionAlgorithm : QCAlgorithm, IRegressionAlgorithmDefinition
    {
        private bool _noDataPointsReceived;
        public override void Initialize()
        {
            SetStartDate(2014, 05, 02);
            SetEndDate(2014, 05, 03);

            var market1 = AddForex("EURUSD", Resolution.Hour, Market.FXCM);
            var firstCustomSecurity = AddData<ExampleCustomData>(market1.Symbol, Resolution.Hour, TimeZones.Utc, false);
            if (firstCustomSecurity.Exchange.TimeZone != TimeZones.Utc)
            {
                throw new RegressionTestException($"The time zone of security {firstCustomSecurity} should be {TimeZones.Utc}, but it was {firstCustomSecurity.Exchange.TimeZone}");
            }

            var market2 = AddForex("EURUSD", Resolution.Hour, Market.Oanda);
            var secondCustomSecurity = AddData<ExampleCustomData>(market2.Symbol, Resolution.Hour, TimeZones.Utc, false);
            if (secondCustomSecurity.Exchange.TimeZone != TimeZones.Utc)
            {
                throw new RegressionTestException($"The time zone of security {secondCustomSecurity} should be {TimeZones.Utc}, but it was {secondCustomSecurity.Exchange.TimeZone}");
            }
            _noDataPointsReceived = true;
        }


        public override void OnData(Slice slice)
        {
            _noDataPointsReceived = false;
            if (slice.Count != ActiveSecurities.Count)
            {
                throw new RegressionTestException($"{ActiveSecurities.Count.ToString().ToCamelCase()} data points were expected, but only {slice.Count} were received");

View on GitHub (pinned to d2c3659f87)

Solutions

  1. Verify the AddData overload being called is the one taking exchangeTimeZone (not fillForward/leverage), and that you pass TimeZones.Utc in the time-zone slot.
  2. If the custom data type overrides time-zone resolution, ensure it does not clobber the value supplied to AddData.
  3. Check the Lean version changelog for AddData signature changes that shifted parameter positions.
  4. Trace through AddData -> SubscriptionDataConfig creation to confirm config.ExchangeTimeZone is the supplied zone.

Example fix

// before: zone silently defaulted to the forex market zone
var s = AddData<ExampleCustomData>(market1.Symbol, Resolution.Hour, false, false);

// after: explicitly pass the exchange time zone in the correct slot
var s = AddData<ExampleCustomData>(market1.Symbol, Resolution.Hour, TimeZones.Utc, false);
Defensive patterns

Strategy: validation

Validate before calling

// Validate the time zone immediately after AddData and fail fast with context
var s = AddData<ExampleCustomData>(market1.Symbol, Resolution.Hour, TimeZones.Utc, false);
if (s.Exchange.TimeZone != TimeZones.Utc)
    throw new InvalidOperationException($"AddData ignored exchange time zone; got {s.Exchange.TimeZone}");

Type guard

bool HasExpectedTimeZone(Security s, DateTimeZone expected) => s.Exchange.TimeZone.Equals(expected);

Prevention

When it happens

Trigger: Calling the AddData overload that accepts a DateTimeZone and reading firstCustomSecurity.Exchange.TimeZone immediately; it returns a different zone (often the underlying forex security's zone or NewYork).

Common situations: Lean version change that altered the AddData time-zone overload signature or default; a refactor that forces the exchange zone to the market-hours zone; or a custom data type whose BaseData.ExchangeTimezone override wins over the AddData argument.

Related errors


AI-assisted analysis of QuantConnect/Lean@d2c3659f87 (2026-08-13). Data as JSON: /api/errors/a287837998ea8501. Report an issue: GitHub.