Accept sub-millisecond fractional seconds in xs:dateTime

[vpaturet]

xs:dateTime places no limit on the number of fractional-second digits, but the
parse formatter in LocalDateTimeISO8601XmlAdapter accepts at most three:

.appendFraction(ChronoField.MILLI_OF_SECOND, 0, 3, true)

A schema-valid timestamp carrying microseconds therefore fails to parse. Because
JAXB routes the resulting DateTimeParseException through the default
ValidationEventHandler, the property is simply left unset — so downstream
consumers see a silent null rather than an error.

This was hit in the wild by OpenTripPlanner on an Italian NeTEx dataset
(opentripplanner/OpenTripPlanner#7956), where a UicOperatingPeriod was
discarded because its FromDate was dropped:

<UicOperatingPeriod version="153" id="IT:ITH4:UicOperatingPeriod:U182_20260416_0">
  <FromDate>2026-05-03T23:30:09.398629+02:00</FromDate>
  <ToDate>2026-08-31T00:00:00</ToDate>
  <ValidDayBits>1111110111111011111101111110101111011111001111100111110011111001111100111110011111001111100111110011111001111100111110011111001</ValidDayBits>
</UicOperatingPeriod>

Note that the +02:00 offset is not the problem — the formatter already has an
optional offset section and discards it, which is the long-standing deliberate
behaviour discussed in #4. It is the six-digit fraction that fails.

The change

One line — widen the fraction to nanosecond precision:

-.optionalStart().appendFraction(ChronoField.MILLI_OF_SECOND, 0, 3, true).optionalEnd()
+.optionalStart().appendFraction(ChronoField.NANO_OF_SECOND, 0, 9, true).optionalEnd()

Both the field and the width have to change. Widening the width alone — as
proposed in #41 — makes parsing succeed but silently truncates, because
MILLI_OF_SECOND can only carry three digits:

input	MILLI_OF_SECOND, 0, 9 (#41)	NANO_OF_SECOND, 0, 9 (here)
...09.398629+02:00	...09.398 (truncated)	...09.398629
...00.012345+01:00	...00.012 (truncated)	...00.012345

Compatibility

Marshalled output is unchanged for every value that can round-trip today. The
fraction stays optional and minimal-width, so whole seconds still emit
2026-08-31T00:00:00 and milliseconds still emit ...09.398. Output differs
only for LocalDateTime values carrying sub-millisecond precision — which
currently cannot enter the model through unmarshalling at all, since they throw.
The wider format only preserves precision that is presently discarded.

There is no measurable parse cost; maxWidth bounds the digit loop rather than
adding work. If anything this is faster on the affected input, since it replaces
exception construction with a successful parse.

Prior discussion

• Fix datetime parsing #41 (2022) proposed the same fix for the same reason ("real-life fares data
  exists that has more than 3 digits"). It received no review and was closed
  unmerged.
• Timestamp with more flexibility (e.g. nanoseconds, spaces as separators) #294 includes this among a broader set of relaxations. Most of that PR accepts
  input that is not schema-valid, which is the basis on which it was
  questioned. This case is the exception: the example above validates against the
  official NeTEx schema and still fails to parse, as demonstrated by
  @stjugi in
  Timestamp with more flexibility (e.g. nanoseconds, spaces as separators) #294 (comment).
  This PR takes only that piece and leaves the rest of Timestamp with more flexibility (e.g. nanoseconds, spaces as separators) #294 untouched.

Not addressed here

parseDefaulting(OFFSET_SECONDS, OffsetDateTime.now()...) is evaluated once at
class-initialisation, baking the JVM's startup offset into a static field, so a
long-running process that crosses a DST boundary keeps a stale offset. It is
also redundant, since the parse target is a LocalDateTime and the offset is
discarded either way.

[leonardehrenfried]

This fixes the problem with the operating period mentioned in the description:

<UicOperatingPeriod version="153" id="IT:ITH4:UicOperatingPeriod:U182_20260416_0">
  <FromDate>2026-05-03T23:30:09.398629+02:00</FromDate>
  <ToDate>2026-08-31T00:00:00</ToDate>
  <ValidDayBits>1111110111111011111101111110101111011111001111100111110011111001111100111110011111001111100111110011111001111100111110011111001</ValidDayBits>
</UicOperatingPeriod>

[leonardehrenfried]

Ref: noi-techpark/opendatahub-mentor-otp#330

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud