LocalDateTime

[skinkie]

At this moment the bindings specifies:

• xs:time LocalTime
• xs:dateTime LocalDateTime
• xs:date LocalDateTime

The first question is, what is the rationale for LocalDateTime opposed to ZonedDateTime or OffsetDateTime? There are at this moment multiple cases where the ZonedDateTime makes more sense, especially in the European Profile.

What is the reason that xs:date is mapped to LocalDateTime opposed to LocalDate?

[csolem]

I think @erlendnils1 is the right one to answer this. We actually did use OffsetDateTime. See the following commit:
7543acf

The reason for this choice of date/time implementation, should be well documented in the readme file for this repository.

[skinkie]

I have the following problem to solve. FlixBus wants to contribute their schedule in NeTEx to Entur. Therefore I have created a FlixBus profile based on their API which is based on DatedCalls. The dated calls are in UTC. Within NeTEx I can do something with default Timezone for the agency, but if I would have to reproces ever LocalDateTime that I see, instead of parse an ISO typestamp that already includes a timezone, it will become a mess.

An additional problem I found was - unlike GTFS - NeTEx does not have timezones on scheduled stop point level (red. it is always via SiteFrame/StopPlace/Locale/TimeZone), if I am wrong at this point I love to be corrected. The only thing I can think of is creating multiple service frames with defaults that group the results per country. I find this also to be very suboptimal.

...and then I still need to transform it to the Norwegain profile ;-)

[erlendnils1]

We did use to map xs:time -> OffsetTime and xs:date & xs:dateTime > OffsetDateTime as Cristoffer stated. The OffsetTime was not suitable as we need to represent repeating vehicle journeys where the offset will differ based on which day we are considering. The xs:time must be treated as LocalTime.

We chose to change OffsetDateTimes to LocalDateTimes at the same time for two reasons:

1. To be consistant with LocalTime
2. Because it makes parsing xs:dateTime without time zone information a lot simpler as we not need to analyze frame defaults in order to create the LocalDateTime.

When it comes "xs:date" I think you are right. These used to be parsed as OffsetDateTime as well, and I guess we simply converted them to LocalDateTime along with the "xs:dateTime". This datatype is rarly used in Netex, typically dates are represented with "xsd:dateTime".

Not quite sure why you would need to specify timezone per ScheduledStopPoint. All TimetabledPassingTimes should be give the relevant local times in the default timezone of the TimetableFrame

[skinkie]

@erlendnils1 I do not understand your reasoning.

The OffsetTime was not suitable as we need to represent repeating vehicle journeys where the offset will differ based on which day we are considering.

OffsetTime stores ZoneOffset for each unique instance, LocalTime does not have this property. Your argument would argue in favor of OffsetTime.

Because it makes parsing xs:dateTime without time zone information a lot simpler as we not need to analyze frame defaults in order to create the LocalDateTime.

I observe this repository as a the place to be for a Java binding to NeTEx, not a keep shortcut for implementing half of the standard inside the binding. Parsing frame defaults and all their variants is at this moment part of the standard, so are timezones. Keeping this Local(Date)Time with this argumentation would not work for me.

Not quite sure why you would need to specify timezone per ScheduledStopPoint.

Because a train from Russia to Europe switches timezones. Hence everything can be distributed in the UTC timezone, the passingtimes will be increasing, but projecting the times on a departure board or journey planner will require to know for which stop this information is relevant.

[erlendnils1]

Consider a service that runs 08:00 local time every day throughout the year. We want to represent this as a single ServiceJourney with identical passing times for the entire year. The 08:00 local time cannot be represented as a single offset timestamp as it would vary according to whether the date you are looking at is within the period of summer time or not. So we (in Norway) would have to represent it as 08:00+01:00 and 08:00+02:00 for different periods. By treating the xs:time fields as LocalTime we do not have this issue.

We agree that current implementation is neither complete nor perfect. If we can create a binding that correctly applies frame default timezones in order to switch to ZonedDateTime instead of LocalDateTime this would be good. Contributions are welcome. In order to cover all use cases for the xs:time fields I think we need something like ZonedTime, which of course is not a part of java.time. It would not be convertable to UTC / offset time without a context date.

When it comes to time zone information for stops we are representing this on the StopPlace entities. This works well as long as we are only assigning StopPlaces to ScheduledStopPoints, but I guess there might be other entities that could be assigned to a ScheduledStopPlace where time zone information is not included in the model.

[skinkie]

Then maybe we should plan a session on this specific topic.

[babadofar]

Any news on this issue? Any ideas how to fix both the 0800 all year repeating journey, as well as the trans siberian railway?

[skinkie]

The 0800 is not a problem, the journey operates at 0800 at the default timezone specified in the Frame, decribe it as Europe/Oslo and you are safe. Depending on what time model you use the trans serberian rail can be described using a timedemandtype, hence only offsets between stations, this works always. With respect to passingtimes and calls, the current model uses DayOffset at every Arrival/Departure hence with changing zones in the timestamp this is not a problem because with respect to the current zone one could calculate the day offset.

[nistvan86]

Any chance of restoring the original functionality?
This makes it really hard to read NeTEx XML files coming from a 3rd party where we have no control over date formats.

Would it be possible to apply the offset to the hour:minutes part of the timestamp before converting it to LocalDateTime? eg. 2019-11-28T23:43:57.099+01:00 becomes 2019-11-29T0:43:57.099. That somewhat eases the problem and at least the timestamp points to a correct instant in the local timezone. Currently the offset part is thrown away.

Unfortunately I don't see any way to post-override the XmlJavaTypeAdapter responsible of doing the conversion (LocalDateTimeISO8601XmlAdapter). Some class loader dark magic might work, but don't like to go that far.

[skinkie]

@nistvan86 the original functionality is far worse. That would be xmlgregoriancalendar and likes. But as I also have suggested, I do wonder why ZonedDateTime is not used.

[nistvan86]

@skinkie I'm completely okay with OffsetDateTime or ZonedDateTime. That's what I meant on "original functionality", the model used those in pre-1.0.8 era if I'm not mistaken.
I think it should be the embedding application's responsibility to decide what to do with the offset part.

[skinkie]

Then I guess we are on the same page. Out of interest. What NeTEx provider is unable to do their job?