NeTEx
NeTEx copied to clipboard
NeTEx-CEN
Write about best practises of using UTC
Since the operator executes their services likely in timezones where day light saving is active, it will effectively cause trips that are operated at an hour difference. Meaning for a UTC timetable, this likely causes a double number of ServiceJourneys, considering a trip leaves at 7am, and will still do so the next day.
The way NeTEx is operating and exchanged focusses on 'paper'. In the daylight saving periode the extra hour does not allow to uniquely identify a trip, iff modelled as a regular ServiceJourney. When UTC is used it can only be used on AvailabilityConditions not crossing a daylight saving border. Otherwise those journeys will have an unmanageable offset.
Yes, this results in a duplication when there exists a daylight saving (well, if it is hourly operated, then not ;-) ).
Where does the unmanageable offset occur in your opinion in the Arrival- and DepartureTime? You can have Zulu time there. So it is right anyhow Or even add the timezone on a per xsd:time base per ArrivalTime/Departuretime.
I think it is the task of the loading system to do timezones right.
Consider you state a DepartureTime=8:00 in UTC. Then at some point the locale of StopPlace defines that these passages occur in Europe/Bern. So we apply 8:00 UTC to Europe/Bern. On March 30 and March 31 there will be another DepartureTime with respect to the local time.
Well... yes...that's the point. As you mentioned => two ServiceJourneys.
But the 08:00 in winter may be then the same as the 09:00 in summer, so it doesn't do a full duplication.
If you don't do it that way and you have a ServiceJourney that starts 25:30 -> 27:30 you would have non continuous increasing times during the switchback in autumn and that is something route planners really don't like. Time loops.
You don't do the latter. The PassingTime is always considered to start at the timezone you are departing from. That is why in some cases UTC certainly makes sence. I would say that a ServiceJourney's availability should never cross DST.