search

public-transport / friendly-public-transport-format

A format for APIs, libraries and datasets containing and working with public transport data.
Creative Commons Attribution Share Alike 4.0 International
125 stars 1 forks source link

expressing realtime / scheduled time data #33

Closed juliuste closed 6 years ago

juliuste commented 6 years ago

When discussing how to handle when and delay for canceled trips in #27, @derhuerst and I became aware of a bigger problem when trying to express time data in FPTF.

There are three possible types of time data you can get from any API/system:

  1. scheduled data only, no realtime information
  2. scheduled data and delay/realtime information, combined
  3. realtime data only, no scheduled information

The current when + delay works well for 2., but things become less clear when you only have either realtime or scheduled time data. In both cases, delay has to be null, but only if you have realtime information, when is accurate. In other words: There should be a way to differentiate between scheduled and realtime data if only one of them is available.

After discussing formerScheduledWhen for canceled trips, @derhuerst and I came up with the following proposal:

Instead of delay and when, we introduce two new fields called scheduledWhen and realtimeWhen. Only one of them is required, if both are set realtime overrides scheduled. This accomplishes our main goal of forcing people to handle both cases properly and should be easier to understand.

One downside of this is that it's going to be "harder" to calculate delay information and people might screw up when subtracting dates (IMHO this is not a dealbreaker, though). Another "bad" thing is that this would be a breaking change.

Opinions? Other proposals? We probably missed something again, I can feel it 😄

juliuste commented 6 years ago

@derhuerst Anything from our discussion that I missed out on?

derhuerst commented 6 years ago

"overwrites" should be changed to "overrides" to be less confusing.

One downside of this is that it's going to be "harder" to calculate delay information and people might screw up when subtracting dates [...].

For me this is sad, but I don't have any better proposal. And I think enabling new use cases for FPTF is worth making the mentioned case harder to deal with.

juliuste commented 6 years ago

See also #5, this is a pretty problematic issue with FPTF right now.

juliuste commented 6 years ago

Moving discussion to #61