Bug: arrival time does not take into account previous delayed arrival

[devilmastah]

Describe the bug I am playing with the VRPTW example and run against a problem with the startServiceTime and Arrivaltime. It is a bit hard to explain, but lets give it a go.

i have 3 orders that get assigned to a specific vehicle like this:

Every bar is 10 minutes Gray is travel time between the orders as estimated by TF Blue is the orders duration. Times on the orders are the duetime and duetime+serviceduration (so expected start and end time) Every order has a 30 minute window between ready and due time.

Actual behavior

• The first order is obviously perfect.
• The second order is delayed about 16 minutes with travel time. (i get back a departure time that is the start service time + the serviceDuration so that seems correct)
• The 3rd order is the problem. Obviously the second was delayed, so i would expect that to reflect on the 3rd as well, even more so since the traveltime even overlaps.

But here the example gives me back a delay of only ~5 minutes which curresponds with what i see on the timeline i made out of it.

Expected behavior I suspect this should be 21 minutes, so 16 minutes of previous delay + 5 minutes traveltime on top of that.

To Reproduce Will need to gather that info together

Environment

Timefold Solver Version or Git ref: release version 1.3.0 i think

Output of java -version: openjdk version "17.0.8.1" 2023-08-24

Output of uname -a or ver: Linux ubuntu 5.15.0-72-generic #79-Ubuntu SMP Wed Apr 19 08:22:18 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Additional information

I might have this wrong and its expected bahaviour, i am quite new to this. But it does not seem right :)

Provide any and all other information which might be relevant to the issue.

[devilmastah]

Actually after a bit of faffing about i think i figured out i interpret the meaning of the two times wrongly. I want to try to have a allowed delay, so i set the readytime to start of the order and duetime to the max allowed delay. I now just offset everything to the front and do the opposite ofset at the output stage.

[triceo]

Hey there @devilmastah,

I'm not sure what to take away from this issue. The original report suggests you think the behavior is a bug, while the comment seems to me like you no longer think it's a bug but you wish there was a different behavior.

Can you please clarify?

[ge0ffrey]

@devilmastah Do you see this behavior on the unaltered vehicle-routing-time-windows quickstart code? Can you give us a reproducer?

[ge0ffrey]

Closing this issue because the screenshot indicates that is this bug is not reported on the original vehicle-routing-time-windows code and there is no proof that the vehicle-routing-time-windows quickstart suffers from this issue. Please reopen if there's a reproducer. We look forward to fix it if the bug does reproduce on the vehicle-routing-time-windows quickstart.