expressing realtime / scheduled time data
juliuste opened this issue · 4 comments
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:
- scheduled data only, no realtime information
- scheduled data and delay/realtime information, combined
- 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 😄
@derhuerst Anything from our discussion that I missed out on?
"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.