test(format/date-time): assert digit character range, separator compliance, and fraction precision

[AcEKaycgR]

Applies to: draft-v1, draft-07, draft/2019-09, draft/2020-12

Adds 7 new cases verifying character digit boundary limits directly adjacent to ASCII numbers, strict separator validation, and arbitrary fractional seconds (secfrac) precision limits for the date-time format.

Added:

• Character just below digit range in year: / (invalid)
• Character just above digit range in year: : (invalid)
• Decimal comma separator instead of period (invalid)
• Slash instead of date hyphen separator (invalid)
• Dot instead of date hyphen separator (invalid)
• Dot instead of time colon separator (invalid)
• Fractional seconds with extremely long 19-digit precision (valid)

Ecosystem Impact (Triangulation):

Under Bowtie verification against 8 active implementations, these cases successfully caught live compliance issues:

1. Rust Bug Caught: rust-jsonschema incorrectly validates "198/-04-12T23:20:50Z" as valid (expected invalid), failing to reject / (ASCII 0x2F directly below 0) in the year component.
2. All other strict active engines correctly rejected character boundary and separator violations.

@jviotti @jdesrosiers @karenetheridge Ready for review.

[jviotti]

Very interesting!

[vtushar06]

@AcEKaycgR Verdicts are correct. The digit-range (198/, 198:) and separator (/, ., decimal comma) cases are all rejected by every validator I tried, so like the others they are coverage rather than divergences - happy to be corrected if you have an implementation that trips one.

The fraction case is the interesting one and I think it is the wrong representative: 1985-04-12T23:20:50.0000000000000000001Z (mostly zeros) breaks nothing. The sub-second case that actually exposes a bug is 1985-04-12T00:59:59.999999999999999Z (second 59, fifteen 9s): ajv-formats full computes Number("59." + fifteen 9s), which is exactly 60.0 in IEEE-754, so it falls into the leap-second branch and rejects a valid input. Fourteen 9s stays under 60.0 and is accepted, so fifteen is the threshold. That's the fraction-precision case worth having - I opened it as #962.

[AcEKaycgR]

Hi @vtushar06,

Thanks for the feedback.

Regarding the digit-range boundary test "198/-04-12T23:20:50Z", it actually does trip a strict engine. rust-jsonschema incorrectly parses it as valid (failing to validate the boundary / character directly below 0 in ASCII).

Also, I saw you opened #962 for the 15-nines fractional second rounding bug in Ajv.