delays

[derhuerst]

How should the delay of a scheduled departure/stopover of a vehicle be specified? Things to consider:

• Do we want a delay field, which contains the time delta, e.g. in seconds?
• Do we want to have another arrival/departure field, that contains the realtime date & time?
• What about a vehicle running earlier? Is that a negative departure?

Information we definitely want to express:

• Is it delayed? If yes, by how much?
• What was the original date & time of departure/stopover?

The most basic format would probably be to add two fields departureDelay and arrivalDelay, which both contain the number of seconds relative to the scheduled departure/stopover.

[derhuerst]

Because we want people to consume realtime data (if available), it should be the most straightforward to use.

I think it's the best to have a arrival/departure field and a arrivalDelay/departureDelay field containing seconds. Another option might be to have arrival/departure and additionally scheduledArrival/scheduledDeparture containing dates.

[derhuerst]

@juliuste opinions?

[derhuerst]

@juliuste ping.

[juliuste]

I'd slightly prefer the arrivalDelay and departureDelay variant. Vehicles running earlier would get a negative delay then (this is not an argument for or against this method, just another opinion on a question from the post above 😄)

[juliuste]

I'm pretty unexperienced with delay information though, so I'd probably change my mind as soon as someone who knows more about this stuff prefers another variant.

[kiliankoe]

Just fyi, the VVO/DVB uses the realTime and scheduledTime approach for their mobile app's API at least (the others either use just realTime and whatever the default for EFA or TRIAS systems are).

I much prefer having a single timestamp and another timedelta. Especially since two timestamps can be in two different timezones (as in DST values) in edge cases (that was a weird and fun issue to encounter 🙄) making naive consumer implementations rather error-prone.

[derhuerst]

@kiliankoe 👍 Then this is pretty much in line with what we discussed before. I like the arrivalDelay and departureDelay fields as time delta as well. Keep in mind that there's a difference between time deltas between localized DateTimes and those deltas between UNIX timestamps (take the DST as an example).

Also keep in mind, that we already incentivise people to do the date/time calculations correctly by using ISO 8601 strings instead of UNIX timestamps, to make sure information like the timezone don't get lost during processing.

Because we want people to consume realtime data (if available), it should be the most straightforward to use.

I would also like to reemphasise on this: It should be the easiest and intuitive thing to consume realtime data (instead of scheduled data), to make sure naive implementations at least use the most accurate available data.

[derhuerst]

@juliuste @kiliankoe To sum it up: any objections with

• arrival & departure being realtime ISO 8601 date/time strings
• having optional arrivalDelay & departuresDelay in seconds, containing the delta of arrival/departure to its planned/scheduled counterpart?