Bug : Timestamp validation error in vrp-pragmatic solution output

[shubham441996]

Summary

The vrp-cli solver successfully finds solutions but panics during output generation due to an invalid timestamp value (i64::MAX = 9223372036854775807) being passed to OffsetDateTime::from_unix_timestamp().

Environment

• OS: macOS 24.5.0 (darwin)
• Rust version: (latest stable)
• vrp-cli version: 1.25.0
• Command used: vrp-cli solve pragmatic

Steps to Reproduce

1. Run the following command:

vrp-cli solve pragmatic /path/to/pragmatic_debug.json --out-result /path/to/solution.json --max-time 10 --heuristic static --log

2. The solver runs successfully and finds a solution:

   • Total jobs: 11
   • Total vehicles: 1
   • Best fitness: (-0.000, 44459.000, 1.000)
   • Generations completed: 35,355 in ~9 seconds

3. Panic occurs during solution output generation

Expected Behavior

The solver should successfully write the solution to the output file without panicking.

Actual Behavior

The solver panics with the following error:

thread 'main' panicked at /Users/shubham.paliwal/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/vrp-pragmatic-1.25.0/src/lib.rs:51:97:
called `Result::unwrap()` on an `Err` value: ComponentRange { name: "timestamp", minimum: -377705116800, maximum: 253402300799, value: 9223372036854775807, conditional_message: None }

Root Cause Analysis

The error occurs in vrp-pragmatic/src/lib.rs:51 in the format_time function:

fn format_time(time: Float) -> String {
    // TODO avoid using implicitly unwrap
    OffsetDateTime::from_unix_timestamp(time as i64).map(|time| time.format(&Rfc3339).unwrap()).unwrap()
}

The function receives a timestamp value of 9223372036854775807 (i64::MAX), which is outside the valid range for Unix timestamps. The OffsetDateTime::from_unix_timestamp() function expects timestamps to be within a reasonable range (approximately -377705116800 to 253402300799).

Additional Information

• The input file contains valid timestamps (e.g., "2025-09-08T12:30:00+00:00")
• The solver successfully processes the problem and finds optimal solutions
• The issue appears to be in the solution serialization phase, not the solving phase
• The output file is created but remains empty (0 bytes) due to the panic

Files Involved

• Primary: vrp-pragmatic/src/lib.rs:51 - format_time function
• Input file: Contains valid timestamps but somehow generates invalid ones during processing
• Output file: Created but empty due to panic

Test Case

The issue can be reproduced with the provided input file. The solver finds a valid solution but fails to output it due to the timestamp validation error.

pragmatic_debug.json

---

Note: This appears to be a data processing issue where valid input timestamps are somehow converted to invalid values during the solving process, causing the output generation to fail.

[rtpg]

I have also experienced this, and tracked it down to the following:

    fn estimate_departure(&self, route: &Route, activity: &Activity, arrival: Timestamp) -> Timestamp {
   ...
   // in some cases (see link)
   return f64::MAX
}

Timestamp here is an f64 but the maximum value for OffsetDateTime::from_unix_timestamp(ts as i64).unwrap() is much less, so when f64::MAX gets looked at over in vrp_pragmatic/src/lib.rs's format_time, everything blows up.

Now in practice I'm a bit confused as to what estimate_departure is trying to do here, but I feel like we should probably have a TIMESTAMP_MAX constant here instead so that Timestamps are still properly Timestamps.

(There is still the possibility of Timestamp overflow in other parts of the codebase I think, at least in theory).