Journey planner API bug - first result significantly in the past

We’re looking to release a new app that includes journey planner functionality next week and it has been getting some more thorough testing.

Something that has been flagged which has not been noticed before (doesn’t necessarily mean it didn’t happen before) is that for some routes the first result has already left, sometimes more than 10 minutes ago. We have not found a pattern to all the journeys where this happens yet, but it almost always seems to happen for routes involving Bank.

The app doesn’t specify a departure time for its journey planner query, but I also reproduced this on the TfL journey planner web app, where an explicit start time is specified. This would appear to be a bug? Can anyone confirm - or has this always been the case?

If this is how the API is intended to function I could filter the results after I get them, but I’d prefer not to as it will reduce the number of results returned for these routes, which sometimes removes a route option.

EDIT - I just randomly tried another route from Amersham to Acton Central and the first train left 19 minutes before the time of the search. Must be a bug - caching issue? Some servers have the incorrect time set?

1 Like

Update: This issue appears to be getting worse. I’m now struggling to find a route where the first API result isn’t in the past by at least a few minutes. On longer routes with infrequent departures I’m even occasionally seeing the first two results in the past, and I’ve seen the first one be more than 30 minutes ago.

1 Like

Ah, I’ve seen this before and I thought it was a feature. Are you using an assumed “now” in your call, or using a specified time?

An assumed “now”. Using the TfL journey planner web app with a specified time still does this though. I fail to see what value there is in telling a user about trains they’ve already missed?? Obviously we are in general getting results from a cache of some kind where possible, but we seem to be going back 1 and very occasionally 2 items too far in that cache. I’d ignore it and just filter them out if it weren’t for the fact that I only get 3 or 4 results for most searches, and the API is sufficiently slow that I’d rather not have to make another call to get more results further in the future.

I’m really hoping it’s a failure mode of some kind rather than a “feature”! Someone pointed it out to me this morning and I did 10 fairly random queries before finding one where the first result was in the past. Now I can’t seem to do any queries without finding old results, which makes me think there’s something not quite normal going on.

Just updating with a new (tied) record for today.

Request at 17:40, Acton Town to Acton Central (yes I have an alphabetical list). First result 17:09 - the second result was at 17:41.

Querying the same result again (double checking I have no local caches being used) at 17:44 I still get the 17:09 route back first. The third result is for 17:49. At 17:47 the 17:09 result was dropped and the 17:41 result is first, the third result is then 18:01. I’m not sure what the logic is behind this, but it really doesn’t make any sense to me.


If it was me, I might be interested in services that are running late, but which I can catch. Perhaps the API is returning trains that are past their departure time but are actually running late?

I know Google Maps API does this with buses.

1 Like

I might be misunderstanding the whole point of the journey planner, but I thought it was supposed to include near-real-time departures, and even uses the anonymised platform crowding data to factor in how long it will take you to change trains. It’s not just a timetable lookup. The departure times should match the ones on the station departure boards (within a little caching/update delay), shouldn’t they?

Anyway, I’d love some official comment on whether this is intended or going to be fixed. If it’s intended I’ll just filter out trains that should have already departed and have a fairly meagre results set in many cases.


Maybe it works differently for the tube but I think JP and Countdown are quite separate, or if they are not that Countdown draws on JP rather than the other way round. Look at any bus journey (departing now) on JP and you find remarkably even gaps between departures and no buses being turned short. Countdown will paint a very different picture.


Thanks. I’ve not looked at buses at all. The trackernet for tube departures is currently down, or I’d compare. I wondered if the two issues were related, or all of our testers have just not noticed the fact that we get results in the past until this Sunday.

If the journey planner is basically just a timetable lookup, I’ll have to look into our own implementation of parts of it, because it’s a bit slow and unreliable in recent months. I can’t see us cost-effectively implementing walking directions to/from the stations though. Google could provide, but it’s too expensive!

I think the reason is probably this:

  • if I ask for a journey tomorrow starting 16:00 and the service is hourly starting 55 minutes past each hour, then it’s useful to tell me about the 15:55 as well as the 16:55, because it’s a future timeslot and its fairly likely that I may want to start my journey a few miinutes earlier rather than getting there an hour later
  • but if I ask for a journey starting now and the time just happens to be 16:00, then I shouldn’t be shown that 15:55 because there’s now no way I can catch that service today

So, properly implemented, the journey planner has to understand the difference between “now” and “16:00 today” and suppress that earlier journey if it was requested as a result of a “now” search.

But my suspicion is that a “starting now” search simply replaces “now” with the current time, and performs the search exactly as if it was a future search, therefore returning historical results. To do the job properly, the journey planner would need to work slightly differently depending whether it was being asked to do a “starting now” search or an absolute time search.

In fact, it’s pretty much certain that the journey planner doesn’t understand that essential distinction between the two cases:

  • in the API, there’s only the option to specify an absolute time. “Starting Now” is not even an option.
  • in the Journey planner public interface, “Starting Now” is the default but it’s immediately converted to an absolute time (which isn’t necessarily even “now” – the start time is actually set up to 14 minutes in the future, as you can see above the displayed results. And then it seems to rely on displaying results that are before the start time, otherwise the journey planner would skip any journeys between now and the next 15 minute period.

So, it’s almost certainly an unnecessary design defect. The journey planner and its API clearly needs a specific flag for “starting now” that doesn’t require using an absolute time, and the results of using that flag should then be tailored to filter out historical journeys.

1 Like

Thanks for the insight! Makes me want to build a better journey planner for “now” that properly takes into account start time, the real-time arrival predictions and (when it’s released) the platform crowding data.