Write about best practises of using UTC

[skinkie]

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.

[ue71603]

@skinkie And what should we propose? Not using UTC?

[skinkie]

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.

[ue71603]

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.

[skinkie]

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.

[ue71603]

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.

[skinkie]

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.

[ue71603]

Perhaps we should ask Wilfried and Alex what they think.

[ue71603]

@duexw @klement-MENTZ