Repository navigation
Stop times > 23:59:59 unsearchable after midnight #23
Description
Activity
Nice catch. Just looking quickly, I think this could be resolved by simple changing the
*_timemembers ofgtfs::stop_timeinto resolvedDateTimes.The comparisons in the query functions are converting them into
DateTimes anyway, so I don't see much of a performance hit. In fact, this could actually be a massive storage improvement (12 bytes perDateTimevs 17 bytes per string representation; 400k stop times would mean megabytes of RAM being saved, plus the indices could be optimized).The issue is that stop times don't actually have associated dates, they're based on the calendar date a trip is active.
Right. Clearly I've been away from this for too long.
A naive solution (sans maybe trans-atlantic aquatic transit support) could be to start the date iteration 2-3 days before the given start date.
A less naive solution might iterate the stop times within the bounds of the query on the index and determine how far back the date needs to go.
I can't think of a better way that wouldn't at least double memory or run time.
For example, this stop time:
75R10,24:02:00,24:02:00,PLZA,3,Warm Springs/South Fremont,,,,1...cannot be found by this
visits_betweenquery:timetable.visits_between("PLZA", "20170728 00:00:00", "20170728 00:30:00", 5)This is because we start searching at day of the requested time.