nautechsystems/nautilus_trader · error · anyhow::Error

Unrecognized execution timezone '{tz_str}' in '{time_str}'.

Error message

Unrecognized execution timezone '{tz_str}' in '{time_str}'. Configure TWS / IB Gateway to emit a standard timezone (e.g. UTC)

What it means

After parsing the naive datetime, parse_execution_time localizes it using the timezone token from the IB timestamp via localize_with_zone. That helper looks the timezone up with get_timezone, and when the token is not a recognized IANA zone or IB abbreviation, this error is thrown, advising the user to configure TWS/Gateway to emit a standard timezone such as UTC.

Source

Thrown at crates/adapters/interactive_brokers/src/execution/parse.rs:441

        localize_with_zone(dt, tz_str, time_str)?
    };

    datetime_to_unix_nanos(utc, time_str)
}

/// Localize a naive timestamp against an IB timezone token and convert to UTC.
///
/// `Z` is normalized to `UTC`; everything else is resolved through the IANA tz
/// database. Error and fold behavior is documented on [`parse_execution_time`].
fn localize_with_zone(dt: DateTime, tz_str: &str, time_str: &str) -> anyhow::Result<Timestamp> {
    let tz_name = if tz_str.eq_ignore_ascii_case("Z") {
        "UTC"
    } else {
        tz_str
    };

    let zone = get_timezone(tz_name).map_err(|_| {
        anyhow::anyhow!(
            "Unrecognized execution timezone '{tz_str}' in '{time_str}'. Configure TWS / IB Gateway to emit a standard timezone (e.g. UTC)"
        )
    })?;
    let ambiguous = zone.to_ambiguous_timestamp(dt);
    match ambiguous.offset() {
        AmbiguousOffset::Unambiguous { .. } => Ok(ambiguous.unambiguous()?),
        // Fall-back fold: take the earliest instant (worst case ~1h skew).
        AmbiguousOffset::Fold { .. } => Ok(ambiguous.earlier()?),
        AmbiguousOffset::Gap { .. } => {
            anyhow::bail!("Execution timestamp '{time_str}' is non-existent in timezone '{tz_str}'")
        }
    }
}

fn datetime_to_unix_nanos(dt: Timestamp, time_str: &str) -> anyhow::Result<UnixNanos> {
    let nanos: u64 = dt
        .as_nanosecond()
        .try_into()

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Set the TWS / IB Gateway API timezone (or the machine timezone it reports) to UTC so timestamps arrive in a standard form.
  2. Install/refresh the tz database (tzdata package) in the deployment environment, especially container images.
  3. Map or normalize non-standard zone names to IANA zones (e.g. 'EST5EDT', 'US/Eastern' -> 'America/New_York') before they reach the adapter.

Example fix

// before
let zone = get_timezone(tz_str).map_err(|_| {
    anyhow::anyhow!(
        "Unrecognized execution timezone '{tz_str}' in '{time_str}'. ..."
    )
})?;
// after
let tz_name = normalize_zone_alias(tz_str); // e.g. "EST" -> "America/New_York"
let zone = get_timezone(tz_name).map_err(|_| {
    anyhow::anyhow!(
        "Unrecognized execution timezone '{tz_str}' in '{time_str}'. ..."
    )
})?;
Defensive patterns

Strategy: validation

Validate before calling

// Rust: pre-check the timezone token against the tz database
fn zone_recognizable(tz_str: &str) -> bool {
    let name = tz_str.trim();
    name == "UTC" || get_timezone(name).is_ok()
}

Type guard

fn is_iana_zone(tz_str: &str) -> bool {
    get_timezone(tz_str.trim()).is_ok()
}

Try / catch

let zone = match get_timezone(normalize_zone_alias(tz_str)) {
    Ok(z) => z,
    Err(_) => {
        tracing::error!("Unknown timezone '{tz_str}' in '{time_str}'; configure TWS/Gateway to UTC");
        return Ok(());
    }
};

Prevention

When it happens

Trigger: An execution timestamp like "20250225 15:15:00 US/Pacific-New" or any token not resolvable by get_timezone reaches parse_execution_time and is passed to localize_with_zone.

Common situations: TWS/IB Gateway set to display times in a non-standard or legacy zone name; tz database differences across machines (missing tzdata on slim Docker images); custom abbreviation like 'CST' that the timezone database rejects.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08). Data as JSON: /api/errors/5d80e4c3f81dc522. Report an issue: GitHub.