Timestamp with more flexibility (e.g. nanoseconds, spaces as separators)

[stjugi]

The parser for time-values is more flexible to accept as well formats like:

• time without seconds, e.g. "15:00+01:00"
• space instead of 'T' as date/time separator
• offset without colon, e.g. "+0100" instead of "+01:00"
• comma instead of dot as decimal separator for fractional seconds
• trailing IANA zone id in brackets, e.g. "+01:00[Europe/Berlin]" (as produced by ZonedDateTime.toString()). The zone id itself is stripped and not interpreted; only the offset and local fields are used.
• date-only input (no time component at all) should default to midnight.

Error correction:

• the parsed result must not depend on "now" (e.g. current DST offset) - it only matters that parsing succeeds and the local fields are correct, regardless of when the test is executed.

[skinkie]

So you now parse invalid data?

[stjugi]

So you now parse invalid data?
No, only accepting more values during the parsing, allowed according to https://en.wikipedia.org/wiki/ISO_8601 .

[skinkie]

No, only accepting more values during the parsing, allowed according to https://en.wikipedia.org/wiki/ISO_8601 .

T is not optional.
https://www.w3.org/TR/2011/CR-xmlschema11-2-20110721/datatypes.diff-wd.html#nt-dateTimeRep

[vpaturet]

This adapter is registered in bindings.xjb for every xs:dateTime → LocalDateTime field, so the change affects the serialized output of all timestamps model-wide.

The old formatter used appendFraction(MILLI_OF_SECOND, 0, 3, true) (minimal digits, omitted when zero); the new OUTPUT_FORMATTER = "yyyy-MM-dd'T'HH:mm:ss.SSS" always prints exactly 3 digits:

Value	Before	After
whole second	2017-01-01T11:00:00	2017-01-01T11:00:00.000
.5	2017-01-01T11:00:00.5	2017-01-01T11:00:00.500

Since this PR is about parsing flexibility, is the change to marshalled output intentional? If not, restoring an optional fraction keeps the on-the-wire format stable for downstream consumers.

[stjugi]

I reviewed the PR and updated the marshaller to the previous format.

[vpaturet]

It looks like I misunderstood the whole thing.
As @skinkie correctly pointed out, xsd:datetime is a subset of ISO-8601, and "making the parser more flexible" actually means accepting invalid XML data that would fail XSD validation, as illustrated by this test: fd86405

I do not think this change belongs to the library. If you need to deal with invalid XML data, that should be handled upstream by filtering/transforming the invalid timestamps.

[stjugi]

No, its not about to import invalid NeTEx: The date format for the import is not following all requirements stemming from ISO 8601 such as :

• time without seconds, e.g. "15:00+01:00"
• offset without colon, e.g. "+0100" instead of "+01:00"
• comma instead of dot as decimal separator for fractional seconds
• trailing IANA zone id in brackets, e.g. "+01:00[Europe/Berlin]" (as produced by ZonedDateTime.toString()). The zone id itself is stripped and not interpreted; only the offset and local fields are used.
• date-only input (no time component at all) should default to midnight.

The PR closes these gaps for the ingoing values. This has nothing to do with an invalid NeTEx to be corrected before importing.

[skinkie]

@stjugi the 'gap' does not exists. Because XML Schema does not support all variants. If you disagree, make a small XML file that have all mentioned variants, show that it passes xml validation (xmllint, with official NeTEx schema). And cannot be parsed in this Java package.