DatedCall should really not have a DayOffset
skinkie opened this issue · 8 comments
If you would create a DatedCall, I would expect that the intention is to have a date and a time, which are combined. The current model allows a Departure and Arrival structure to have a time with a DayOffset this will obviously lead to very strange ambiguities.
Can we check if this should be restricted?
If I remember well the day offset on Call is necessary due to the fact that some vehicle journeys can last several days (a trans-European bus for example), and you need to know on which day of the journey you are.
If I remember well the day offset on Call is necessary due to the fact that some vehicle journeys can last several days (a trans-European bus for example), and you need to know on which day of the journey you are.
On a call, sure, but we are talking about a DatedCall which has departure_date and arrival_date. So if this means we need restriction ;-) sure. But I would prefer a better object inherintance.
Documentation could state that explicit date and time takes precedence over Offset, but Offset is still useful to have for passenger information "Next day " or "two days later" so as to make clear. people can get very confused over pms and ams
Documentation could state that explicit date and time takes precedence over Offset, but Offset is still useful to have for passenger information "Next day " or "two days later" so as to make clear. people can get very confused over pms and ams
The point is that an offset is something else than an explicit date. If we now consider an offset being an attribute instead of a qualifier... it does not make sense if in an other case it is a qualifier.