What causes "seconds timestamp should fit i64" in nautechsystems/nautilus_trader?

Feed the generator real wall-clock epoch seconds instead of synthetic u64 values

seconds timestamp should fit i64

Error message

seconds timestamp should fit i64

What it means

This panic comes from `i64::try_from(epoch_second).expect("seconds timestamp should fit i64")` inside `write_fixed_prefix` in crates/common/src/generators/position_id.rs. The function builds the fixed date-time prefix for generated PositionId values and needs to hand the epoch seconds to jiff's `Timestamp::from_second`, which takes i64. An epoch_second value that cannot fit in an i64 is treated as an invariant violation and panics.

Source

Thrown at crates/common/src/generators/position_id.rs:133

    }

    #[inline]
    fn refresh_fixed_prefix(&mut self, timestamp_ms: u64) {
        let epoch_second = timestamp_ms / 1_000;
        if epoch_second == self.epoch_second {
            return;
        }

        write_fixed_prefix(&mut self.buf, &self.trader_tag, epoch_second);
        self.fixed_prefix_len = self.buf.len();
        self.epoch_second = epoch_second;
    }
}

fn write_fixed_prefix(buf: &mut String, trader_tag: &str, epoch_second: u64) {
    let now_utc = Offset::UTC.to_datetime(
        Timestamp::from_second(
            i64::try_from(epoch_second).expect("seconds timestamp should fit i64"),
        )
        .expect("seconds timestamp should be within valid range"),
    );

    buf.clear();

    write!(
        buf,
        "P-{:04}{:02}{:02}-{:02}{:02}{:02}-{trader_tag}-",
        now_utc.year(),
        now_utc.month(),
        now_utc.day(),
        now_utc.hour(),
        now_utc.minute(),
        now_utc.second(),
    )
    .expect("writing to String should not fail");
}

View on GitHub (pinned to 18893faf8b)

Solutions

Feed the generator real wall-clock epoch seconds instead of synthetic u64 values
Validate/clamp the u64 upstream: reject values exceeding i64::MAX as u64
Fix test fixtures to use realistic epoch seconds

Example fix

// before
let bad_epoch: u64 = u64::MAX;
generator.refresh_fixed_prefix(bad_epoch);
// after
let epoch: u64 = current_unix_seconds();
assert!(epoch <= i64::MAX as u64);
generator.refresh_fixed_prefix(epoch);

Defensive patterns

Strategy: validation

Validate before calling

fn valid_epoch_seconds(secs: u64) -> bool { secs <= i64::MAX as u64 }

Prevention

Use the real clock as the source of epoch seconds
Validate u64-to-i64 conversions at the boundary

When it happens

Trigger: Calling `refresh_fixed_prefix` for the PositionIdGenerator with an `epoch_second: u64` larger than i64::MAX. Ordinary Unix time can never reach this; only synthetic/overflow values trigger it.

Common situations: Fuzz or property tests supplying u64::MAX, an overflowing or uninitialized nanos-to-secs conversion feeding the generator, or corrupt clock state in a test harness.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

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