ZonedDateTime

[ue71603]

Currently it is open to interpretation whether local time or UTC (Zulu-Time) is used (when not Z or time zone is indicated).

The basis is DateTime

The burden of interpreting the time into a local time needs to be done by the client system.

We were asked, whether it would not be better to switch to "ZonedDateTime" and to put the burden on the server.
While Java has a ZonedDateTime. XML does not per se.

Perhaps even to have a parameter switching.

[skinkie]

It is not an open interpretation. It is what the xs:dateTime defines.

Optional. If present, represents the time zone. If a time zone is not specified the dateTime has no timezone; however, an implicit time zone of UTC (Coordinated Universal Time, also called Greenwich Mean Time) is used for comparison and arithmetic operations.

ZonedDateTime is an implementation detail, specifically for the Java binding. What OJP, as standard, should do is define that a timezone must be mandatory, I think it only can be enforced using a regular expression.

[ue71603]

I agree. Two possibilities:

• In the xs:documentation. We make it clear, that the timezone should be used
• We create a new element that does it :-)

Or you object to the thing in priniciple.

I think Peter is more concerned on putting the UTC->local conversion onto the client (what the Swiss implementation currently does).

[skinkie]

To be honest, I think the best thing for this standard is to export exclusively UTC. Then the presentation layer chooses what timezone to be presented. This avoids OJP to become a presentation format.

[ue71603]

That is one use case.

What Peter wants is: "Show local time" for all stops. This is not what the presentation does naturally. I think it is about processing/implementation.

[skinkie]

I would like to avoid this. But I would see this use case. I would even then go for an enumeration like local, utc, native.

[phirzel]

Correct, that is what I want to prevent: putting the UTC->local conversion onto the client
It is very hard to derive the correct TZ for a StopPoint if u get only UTC from OJP (problems like, what was the origin base for TZ assignment, especially where EFZ TZ does not match the geograpical TZ, or StopPoints have no coordinates, not all StopPoints have a SLOID and are therefore not obviously in "Europe/Zurich".

Please make technical and business aspects match together -> this is such an important detail in routing!

I believe both aspects can be merged in Java ZonedDateTime or OffsetDateTime easily (if XML Gregorian or what ever can't do it, extend it whatever you find best to allow it). I am convinced, the router must know the correct Timezone while routing, so just pass it on. The client may still convert the given data into any other Timezone of its choice, but with proper shifts.

[leonardehrenfried]

I'm implementing an OJP interface in OpenTripPlanner and I have noticed this issue. I would prefer if the OJP schema forced you to always use a date time with the offset. Right now a time without a time zone would be allowed leading to ambiguities.

I am on the side of @phirzel when it comes to which time zone to use. For a server it will be much easier to select the zone that matches the location of the stop. For clients it will be harder (even if I agree that you could argue that it is presentation logic.)

In other OTP APIs (GraphQL) we always use the local time zone, not UTC. Example.

[felixguendling]

To be honest, I think the best thing for this standard is to export exclusively UTC. Then the presentation layer chooses what timezone to be presented. This avoids OJP to become a presentation format.

This is similar to what MOTIS does. We return the timestamp in UTC and additionally the timezone (like Europe/Berlin) of each location, so the client can show whatever information is needed (UTC, timezone, local time).