juliuste
commented
3 years ago Hey Jonas, thanks for reporting this! I implemented the change you suggested in 0852c571ca330ae8c767a628efea315a8ba41071, which should fix the examples you posted above.
Unfortunately, the endpoint we're using seems to have several bugs which lead to this weird behaviour. I'm pretty sure there are also cases of trains running for 100h or so within Germany, which won't be fixed with this static upper bound. Since the API endpoint that we're using is deprecated, there is little hope that these will get fixed soon. To fully resolve this, one would need to completely change the way this service is working. (It would probably make sense to calculate all durations from a validated, static dataset instead of using the deprecated API on-demand, but since such a dataset is not public as of now, one would need to write a scraper first, which takes additional time).
I'll close this issue for the time being, but if you - or anyone else reading this - finds examples of trains that are still broken (ones that take less than 210h, I'm pretty sure that these exist and that I saw them already in the past), please re-open and post screenshots/descriptions here.
Occasionally, the pop-ups on https://direkt.bahn.guru/ show travel durations that are by 360 h = 15 d too high. These numbers are reproducible.
Examples:
The wrong travel durations seem to come from the API. Without having tracked down the specific cause for this issue, a simple fix might be to filter out these travel times in the
reachableForDayfunction. Currently, there seems to be no train on the world that runs for more than 206 h.