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.