Open deingithub opened 4 months ago
I'll probably postpone this until I have refactored and thoroughly unfucked the current timestamp situation in travelynx. It's the root of at least one nasty and hard-to-reproduce bug already.
Okay, kein Problem!
Moin,
this is a patch aspiring to fix #90 and #83. Currently the HAFAS backend in various places picks the first stop on the route that matches the EVA/name of the requested checkin and checkout points, without considering the arrival and departure times. The IRIS backend appears to have these checks in place already— https://github.com/derf/travelynx/blob/c04e58a8e46b73f8befe870fffdaff9bd9b3edfc/lib/Travelynx.pm#L767-L776
i've added the same kind of checks to various places:
_checkin_hafas
and_checkout_hafas
functions do a somewhat-lenient match on the provided timestamp to find the correct stop.index.pl work
automatic checkout has also been patched to consider the timestamps.some notes:
add_route_timestamps
hasn't been called yet and no timestamp data is available. this is worked around by just ignoring unknown time values, but it would be a good UI improvement and reduce these edge cases if it was possible to delay rendering the view untiladd_route_timestamps
has been called. i was not able to do that.sched_arr
,sched_arrival
,sched_arr_ts
,sched_arrival_ts
, each one might be aDateTime
, an epoch seconds number or undefined altogether and handling them with anything less than the very verbosely-named helper function that i wound up writing is a recipe for hard to predict "can't compare DateTime with undef" or whatever issues. on the long term some comments and documentation on from what contexts these functions might be called would be greatly appreciated.Cheers c: