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.