add plannedArrival/plannedDeparture

[derhuerst]

This PR adds plannedArrival/plannedDeparture to journey legs.

Note sure if you want this in trias-client or not. In public-transport/friendly-public-transport-format#61 there has been a lot of discussion about this, as you've probably seen (I need to reply to you!), and it looks like FPTF v2 will have these fields; Also, hafas-client already has them today.

Keep in mind that the leg.line.id change (40fcc97) is a breaking change!

still to do:

• add plannedWhen to arrivals/departures
• do you want to adapt the tests?

[andaryjo]

I did not follow the original discussion that closely, but I think I got the idea. Personally, I might have a different opinion on how to structure scheduled/planned/realtime data, but this would be better placed in the respective FPTF issue. trias-client will incorporate whatever changes are made to FPTF.

However, maybe we should finalize version 2 of the FPTF before making adjustments to the clients. I realize that this discussion has been ongoing for a long time, but we should finally commit to a new standard that all consumers can rely on.

[andaryjo]

d83ece6 also seems like a breaking change to me. Current applications are expecting arrival or departure to always contain the planned time and calculate the realtime using the delay. This behavior will change.

[derhuerst]

Current applications are expecting arrival or departure to always contain the planned time and calculate the realtime using the delay.

Are you sure this is the case?

<TimetabledTime> is documented as "Zeit nach Fahrplan." in the German TRIAS 1.2 documentation.

[andaryjo]

Right, TimetabledTime always contains the planned time and EstimatedTime contains the real time and gets only populated if available. The trias-client currently always parses TimetabledTime to departure and adds the delay attribute if EstimatedTime exists.

If I understand it right, with the new behavior, trias-client would return either TimetabledTime or EstimatedTime (if existing) as departure. But current consumers of the trias-client (or at least my own applications) always expect departure to be the planned time and only retrieve the real time by adding the delay (if existing). So this would then be a breaking change for existing consumers.

But maybe I got it wrong... 😄