Deal with timestamp overflows

[rtpg]

I've sent these changes upstream here, along with comments, so might be worth looking over there to see what's up on these changes

[kraklo]

If I understand this correctly, basically the crashes we were getting was due to format_time trying to format Float::MAX/f64::MAX as that's what's being used as an arbitrary max in every case.

There are also a couple of other places that seem to be checking for Float::MAX, such as

vrp/vrp-core/src/construction/enablers/schedule_update.rs

Line 85 in e3956e9

let latest_arrival_time = if end_time == Float::MAX {

vrp/vrp-core/src/models/common/domain.rs

Line 81 in e3956e9

Self { start: 0., end: Float::MAX }

(and also line 177 and 202)

vrp/vrp-core/src/models/problem/fleet.rs

Line 179 in e3956e9

end: detail.end.as_ref().and_then(|e| e.time.latest).unwrap_or(Float::MAX),

vrp/vrp-core/src/models/solution/route.rs

Line 91 in e3956e9

place: Place { idx: 0, location: 0, duration: 0.0, time: TimeWindow { start: 0.0, end: Float::MAX } },

and like a bunch of other places.

Given that the author has used this ubiquitously everywhere, and it's most probably too much effort to try and change it everywhere, I wonder if the only real change that needs to happen is in format_time, given that seems to be the only place where a range error could be encountered.

[kraklo]

I wonder if we could just let time handle range errors by letting it return ComponentRange and handling it properly instead of just unwrapping it, using some sort of default MAX_DATETIME or placeholder "Max Date" string.

OffsetDateTime::from_unix_timestamp(time as i64)
    .unwrap_or_default(MAX_DATETIME)
    .format(&Rfc3339).unwrap()

or

let time_result = OffsetDateTime::from_unix_timestamp(time as i64)

match time_result {
    Ok(time) => time.format(&Rfc3339).unwrap(),
    Err(_) => String::from("Max timestamp"),
}

[rtpg]

main worry there is that given this is an f64 the sign might be like "max datetime or min datetime" (if we ended up with f64::NEG_INFINITY for example)

not that I think there's any place in the code that does -timestamp but there might be code that does departure - arrival, and then we end up with f64::NEG_INFINITY or something approaching f64::MIN casting out to MAX_DATETIME rather than MIN_DATETIME.

[rtpg]

Ah! I was searching for f64::MAX, but missed Float::MAX.

Will send in a different set of changes that just goes for the minimal thing

[rtpg]

not to get too in the weeds but the error message should be a &'static str and this expect call ... shouldn't really cost much/anythig comp[are to unwrap

[rtpg]

haven't seen anything near MIN_TIMESTAMP but the handling is the same and it reduces the window of failure

[adamdickinson]

Could you confirm this works with a sample erroneous payload?

[rtpg]

So this minimal fix prevents crashes... in release mode! in dev this crashes

The actual scheduling result is the case of breaks does still look nonsensical though.

                      {'activities': [{'jobId': '23',
                                       'location': {'index': 22},
                                       'time': {'end': '2025-11-27T02:15:35Z',
                                                'start': '2025-11-27T00:15:35Z'},
                                       'type': 'service'},
                                      {'jobId': 'break',
                                       'time': {'end': '2025-11-27T02:00:00Z',
                                                'start': '2025-11-27T01:30:00Z'},
                                       'type': 'break'}],
                       'distance': 8764,
                       'load': [0],
                       'location': {'index': 22},
                       'time': {'arrival': '2025-11-27T00:15:35Z',
                                'departure': '9999-12-31T23:59:59Z'}},
                      {'activities': [{'jobId': '24', 'type': 'service'}],
                       'distance': 23999,
                       'load': [0],
                       'location': {'index': 23},
                       'time': {'arrival': '9999-12-31T23:59:59Z',
                                'departure': '9999-12-31T23:59:59Z'}},
                      {'activities': [{'jobId': '11', 'type': 'service'}],
                       'distance': 31748,
                       'load': [0],
                       'location': {'index': 11},
                       'time': {'arrival': '9999-12-31T23:59:59Z',
                                'departure': '9999-12-31T23:59:59Z'}},