test(format/date-time): add boundary whitespace and anchoring validation cases

[AcEKaycgR]

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

Adds 6 new cases validating strict string anchoring constraints, boundary whitespace, and component-only (date-only/time-only) compliance for the date-time format.

Added:

• Empty string (invalid)
• Leading whitespace before valid date-time (invalid)
• Trailing whitespace after valid date-time (invalid)
• Trailing garbage content after valid date-time (invalid)
• Date-only string (invalid)
• Time-only string (invalid)

Ecosystem Impact (Triangulation):

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

1. Go Bug Caught: go-gojsonschema incorrectly validates both the date-only string ("1985-04-12") and the time-only string ("08:30:06Z") as valid (expected invalid), failing to enforce that a full date-time must contain both components.
2. All other active strict engines (Rust, PHP) correctly rejected these.

@jviotti @jdesrosiers @karenetheridge Ready for review.

[jviotti]

Looks good to me!

[vtushar06]

@AcEKaycgR I went through these against RFC 3339 section 5.6 and ran each one through ajv-formats (full and fast) and python-jsonschema. The verdicts are all correct.

One thing on the suite bar: the convention we've been holding to (for example the ipv4 PRs #907/#908/#909, and @jdesrosiers said on #904) is that each new test should expose a divergence in a real implementation - otherwise it's coverage that every validator already handles. I ran all six here and none of them is accepted or rejected wrongly by ajv or python; both already reject the empty string, the leading and trailing space, Z extra, the date-only and the time-only strings. Could you add which implementation each of these actually trips? If they don't trip any, they may not clear that bar.

For the anchoring case that does trip one, I opened #959: a trailing newline 1985-04-12T23:20:50Z\n. python-jsonschema accepts it because rfc3339-validator does re.match(RFC3339_REGEX + "$", value) and Python's $ matches just before a single trailing \n - so Z and Z extra (which you have here) get rejected, but Z\n slips through.

[vtushar06]

@jviotti @jdesrosiers The anchoring case that does trip one is the trailing newline: 1985-04-12T23:20:50Z\n. python-jsonschema accepts it (wrong). Its date-time check goes through rfc3339-validator, which does re.match(RFC3339_REGEX + "$", value), and Python's $ matches just before a single trailing \n - so Z and Z extra (which you have) get rejected, but Z\n slips through. That's the one I'd swap in for this category.

Also note all six inputs here are already in your #891, so this overlaps that PR so either need to close that one.

[AcEKaycgR]

Hi @vtushar06,

Thanks for the feedback.

While Ajv and Python do reject them, these cases actually trip another strict engine. Go's go-gojsonschema incorrectly parses both the date-only (1985-04-12) and the time-only (08:30:06Z) strings as valid (expected invalid), failing to enforce that a full date-time must contain both components. That is the implementation gap these tests are targeted to catch.