Created attachment 183298 [details] The bug in action SUMMARY When selecting an arrival time for a trip, the app shows results for the next available trip instead of at the desired time STEPS TO REPRODUCE 1. Open KDE Itinerary 2. Enter your destination and starting point 3. Chose a time of Arrival in the future 4. Search journey OBSERVED RESULT The available trips are the next possible ones EXPECTED RESULT The trip shown should take the desired arrival time into account SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon User Edition x86_64 Kernel: 6.14.0-24-generic KDE Plasma Version: 6.4.3 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 ADDITIONAL INFORMATION
The arrival time is taken into account, the problem seems to rather be that we don't flip the sort order in arrival mode, ie. you currently need to scroll to the end of the list to find the results you would expect (this becomes more obvious when selecting an arrival time a few days into the future).
A possibly relevant merge request was started @ https://invent.kde.org/pim/itinerary/-/merge_requests/412
(In reply to Volker Krause from comment #1) > The arrival time is taken into account, the problem seems to rather be that > we don't flip the sort order in arrival mode, ie. you currently need to > scroll to the end of the list to find the results you would expect (this > becomes more obvious when selecting an arrival time a few days into the > future). Perhaps another way to look at it would be to have all times available, and set the scroll to the closest to the selected arrival time. Thus not changing the paging order and keeping all results easily accessible.
Git commit 41466600ef93d8e0c25593449888b28580a9ae29 by Volker Krause. Committed on 14/09/2025 at 09:51. Pushed by vkrause into branch 'master'. Initially position journey result view at the end for arrival searches We can only reliably do this after the first result batch has been added, for later batches the user could have manually changed the scroll position which we cannot reliably detect and which we must not override. However, this is probably close enough in most cases, as subsequent batches will come from other backends and as such will primarily be before rather than after the previously last result. M +12 -0 src/app/JourneyQueryPage.qml https://invent.kde.org/pim/itinerary/-/commit/41466600ef93d8e0c25593449888b28580a9ae29
Git commit ea5c1c605888ba465badd12c886bbb4993a050f1 by Volker Krause. Committed on 14/09/2025 at 14:14. Pushed by vkrause into branch 'release/25.08'. Initially position journey result view at the end for arrival searches We can only reliably do this after the first result batch has been added, for later batches the user could have manually changed the scroll position which we cannot reliably detect and which we must not override. However, this is probably close enough in most cases, as subsequent batches will come from other backends and as such will primarily be before rather than after the previously last result. (cherry picked from commit 41466600ef93d8e0c25593449888b28580a9ae29) M +12 -0 src/app/JourneyQueryPage.qml https://invent.kde.org/pim/itinerary/-/commit/ea5c1c605888ba465badd12c886bbb4993a050f1