nautechsystems/nautilus_trader · info

valid UTC week start

Error message

valid UTC week start

What it means

Immediately after computing the week start date, `get_time_bar_start` converts `week_start_date.at(0,0,0,0)` (midnight UTC) into a timestamp with `Offset::UTC.to_timestamp(...).expect("valid UTC week start")` (crates/model/src/data/bar.rs:246). This fails only if the civil datetime is outside the range convertible to a jiff Timestamp, i.e. dates beyond roughly ±9999 years — not possible for real Unix timestamps.

Source

Thrown at crates/model/src/data/bar.rs:246

            find_closest_smaller_time(now, origin_offset, SignedDuration::from_secs(step))
        }
        BarAggregation::Minute => {
            find_closest_smaller_time(now, origin_offset, SignedDuration::from_mins(step))
        }
        BarAggregation::Hour => {
            find_closest_smaller_time(now, origin_offset, SignedDuration::from_hours(step))
        }
        BarAggregation::Day => find_closest_smaller_time(now, origin_offset, duration_days(step)),
        BarAggregation::Week => {
            let now_civil = Offset::UTC.to_datetime(now);
            let days_from_monday = i64::from(now_civil.weekday().to_monday_zero_offset());
            let week_start_date = now_civil
                .date()
                .checked_sub(jiff::Span::new().days(days_from_monday))
                .expect("valid week start");
            let mut start_time = Offset::UTC
                .to_timestamp(week_start_date.at(0, 0, 0, 0))
                .expect("valid UTC week start");
            start_time += origin_offset;

            if now < start_time {
                start_time -=
                    duration_days(step.checked_mul(7).expect("`step` overflows i64 days"));
            }

            start_time
        }
        BarAggregation::Month => {
            // Set to the first day of the year
            let now_civil = Offset::UTC.to_datetime(now);
            let mut start_time = Offset::UTC
                .to_timestamp(
                    Date::new(now_civil.year(), 1, 1)
                        .expect("valid year start date")
                        .at(0, 0, 0, 0),
                )

View on GitHub (pinned to 18893faf8b)

Solutions

1. No action needed for genuine UnixTimestamp inputs.
2. If encountered, verify the `now` parameter is a valid UnixTimestamp rather than a corrupted value.
3. File an issue with the reproducing timestamp if hit on real data.

// rust
fn timestamp_in_reasonable_range(now: UnixNanos) -> bool {
    let secs = now.as_u64() / 1_000_000_000;
    secs > 0 && secs < 253_402_300_799
}

When it happens

Trigger: Practically unreachable for real timestamps; requires the derived week-start midnight datetime to fall outside jiff's Timestamp range.

Common situations: Only from synthetic/extreme `now` values or a library-level bug; never in normal operation.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• valid week start
• valid year start date
• valid UTC year start
• seconds timestamp should be within valid range
• seconds timestamp should be within valid range

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