Bug 507149

Summary: Arrival time not taken into account
Product: [Applications] KDE Itinerary Reporter: MathieuM <mathieu>
Component: generalAssignee: Volker Krause <vkrause>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version First Reported In: 25.04.3   
Target Milestone: ---   
Platform: Neon   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: The bug in action

Description MathieuM 2025-07-17 08:50:56 UTC
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
Comment 1 Volker Krause 2025-07-17 16:02:06 UTC
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).
Comment 2 Bug Janitor Service 2025-07-17 16:04:35 UTC
A possibly relevant merge request was started @ https://invent.kde.org/pim/itinerary/-/merge_requests/412
Comment 3 MathieuM 2025-07-17 16:11:48 UTC
(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.
Comment 4 Volker Krause 2025-09-14 09:57:52 UTC
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
Comment 5 Volker Krause 2025-09-14 14:14:52 UTC
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