The counter time_since_last_loading added here seems to be similar to last_station_departure_date from #9093.

• In Feature: [NewGRF] vehicle var 0x4E, 'date of last station departure' #9093 an absolute time was considered better than a relative time.
• Feature: [NewGRF] vehicle var 0x4E, 'date of last station departure' #9093 seems to care only about the date, while this PR cares about ticks.
• Feature: [NewGRF] vehicle var 0x4E, 'date of last station departure' #9093 is pretty unclear about when to set the counter "loading", "unloading", "stopping"...

Is it the same? or is there an important difference that makes it necessary to add two similar but distinct time stamps?

I thought about using a date, the code would be a bit simpler but it would be a bit less precise. More importantly, it would break when using the cheat that changes the current year. While working on this PR I found out that setting the current year does break date_of_last_service a bit in master, I will probably open a bug or a PR about that later.

The time I store does not exactly correspond to the date of last station departure because to fix #9665 the variable introduced by my PR has to be exactly the time since last_loading_station was last updated, which is very specific (see Vehicle::LeaveStation() for the exact conditions). So it makes sense to have three similar but separate variables current_order_time, time_since_last_loading and last_station_departure_date.

Isn't it possible to just store current vehicle tick and do some math when the exact value is needed ? And remove most counters.

Without the time since last loading, you would probably need to store the date of last loading, which has its advantages (no need to increment the counters) and drawbacks (lower resolution, problems when using cheats and when reaching last valid year).

I grep'd for current_order_time to determine where I should increment time_since_last_loading, so assuming the former works fine, hopefully the latter will too.

I looked a bit more into your suggestion and I think _date * DAY_TICKS + _date_frac as an int64 would probably work as a tick counter. Should I replace the counter introduced in this PR with a timestamp in ticks and deduce the travel time from it?

As suggested, I replaced the tick counter with a date in the fix to #9665. I also added a trivial fix to #9708.

Could someone please have another look at this PR?

Ping. Cargodist is severely broken for some networks since OpenTTD 12.0 (#9665, #9708), and this PR aims to fix it.
I can always split it into several PRs if you are not convinced by some of the commits.

I rebased onto master. #10035 makes the third commit simpler, I now use _tick_counter instead of _date_frac to compute durations in ticks.