Train lateness - realtimetrains vs recenttraintimes

[akm]

On Wednesday, the 1700 from London Waterloo to Portsmouth (1P53) left a little bit late and on arrival was a bit more late. My wondering is, just how late was it when it arrived at Fratton?

RealTimeTrains, at https://www.realtimetrains.co.uk/service/gb-nr:L79713/2026-09-23/detailed, says:



That it was 15 minutes late, arriving 1845 as compared to a GBTT and WTT scheduled arrival of 1830 (the first two columns).

However, RecentTrainTimes, at https://recenttraintimes.co.uk/Home/Service?ServiceId=148577036, says:



That it as 14 minutes late, arriving at 1844.

It won't surprise anyone to learn that the TOC is going with the latter time, on my Delay Repay claim

What are the sources of these arrival times, and how come they differ?

 

[Crithylum]

Most websites use Darwin (the official data source they are meant to reference), whereas Realtime Trains uses Trust. Realtime Trains only has data of when trains enter signalling blocks and then guesses* when the train stopped. Darwin also only has access to signalling blocks, but then The Railway also does its "official" calculation. Realtime Trains is far more accurate in almost every situation.


*there is alot of work that goes into making this accurate

 

[Haywain]

Realtime Trains uses Trust.

RealTimeTrains uses both Trust and Train Describer data for the actual timings shown and, in the case of the OP's train, is using the latter. This may not be exactly the same as shown in Trust as that only uses whole minutes.

== Doublepost prevention - post automatically merged: Today at 11:05 ==

In the case of the train that the OP used, the arrival time is shown as 18:44 in Trust.

 

[Tom]

The actual full time RTT has for Fratton on that service is 18:45:06, the SMART time (ie what's in TRUST) is 18:44:56 - interestingly it looks like Fratton has been re-audited recently (in May 2026) in SMART.

It would be interesting to know how many shorter trains fed into that SMART time though.

 

[CharlieSpotted]

I know a line has to be drawn somewhere, but imagine being the type of organisation that denies someone a small amount of compensation for a delay that is 4 seconds under the threshold, instead of just sucking it up and paying it out ...

... and then add on the fact that the customer can't even see that timing so has no way to know they're 4 seconds out!

 

[Haywain]

I know a line has to be drawn somewhere, but imagine being the type of organisation that denies someone a small amount of compensation for a delay that is 4 seconds under the threshold, instead of just sucking it up and paying it out ...

... and then add on the fact that the customer can't even see that timing so has no way to know they're 4 seconds out!

As I said, the time shown in Trust is 18:44 - whole minutes only, not seconds as well. I am not aware of anywhere in Trust that will show the time down to seconds, but can only assume that @Tom is referring to a source that feeds into Trust.

 

[Tom]

Seconds are truncated on entry into TRUST, but the times are calculated including seconds. SMART is what does the work to convert a train describer step into a TRUST automatic report.

But bear in mind Darwin (where recent train times derives its data from I think) can have its own set of offsets too.

 

[Watershed]

If you really want to pursue it, you could put in a Subject Access Request to SWR for any footage showing you alighting from the train. That should be timestamped and with any luck might even show a station clock too. Then again it's a question of whether it is worth it over 25% of a single or 12.5% of a return (or the equivalent for rovers/seasons)...

Delay Repay portals really should be accounting for the fact that stopping ≠ opening the doors. If the train was marked as stopping at 18:44:56 then it is extraordinarily unlikely that the doors actually opened before 18:45:00 given the guard release that SWR use and the slow doors on the 444/450s.