test(format/date): add boundary whitespace, Unicode dash, and max boundary cases

[AcEKaycgR]

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

Adds 8 new edge cases validating strict string anchoring constraints, Unicode whitespace characters, alternative Unicode dash variations, and maximum boundary years for the date format.

Added:

• Leading tab character before valid date (invalid)
• Trailing newline after valid date (invalid)
• Leading non-breaking space before valid date (invalid)
• Unicode en dash separators (invalid)
• Unicode minus sign separators (invalid)
• Maximum boundary full-date year 9999 (valid)
• Partial date-time prefix with T suffix (invalid)
• Partial date-time prefix with hour component (invalid)

Rationale for separating Unicode en dash and Unicode minus sign:

We explicitly test both – (U+2013, General Punctuation block) and − (U+2212, Mathematical Operators block) because they belong to completely separate Unicode blocks. Implementations that perform partial Unicode normalization or range checks (e.g., stripping punctuation blocks vs mathematical symbol blocks) could reject one while erroneously normalizing and accepting the other.

@jviotti @jdesrosiers @karenetheridge Ready for review.

[jviotti]

Looks spec-correct but again would be nice to see if any existing implementation gets tripped up by any of these new ones to have more insights on their value compared to the existing ones!

[AcEKaycgR]

Thanks for the approval, @jviotti

Under Bowtie verification, these cases successfully caught a live bug in opis-json-schema (PHP), which incorrectly validates the trailing newline case "2020-01-01\n" as valid due to a regex anchoring gap. Other strict engines like Go and Rust correctly reject it.

[jdesrosiers]

The only test here that I think we should keep is the year boundary test.

[jdesrosiers]

I'm not convinced these are needed. These characters aren't special because the look similar to -. IMO, this is the same test as 2020/01/01, which we're already testing.

[jviotti]

Of course I would like to see proof, but I wouldn't be surprised if because these characters look similar to the human eye some implementations try to be lenient on it, without thinking about the fact there are standards behind it

[jdesrosiers]

These aren't meaningfully different than the tests that check for anything after the date.

[AcEKaycgR]

Hi @jdesrosiers,

You're completely right on the Unicode dash and prefix cases. I've removed those to keep the PR minimal.

Regarding the trailing newline (\n), we actually have a concrete example of this exact discrepancy In the PHP ecosystem, php-opis-json-schema incorrectly validates 2020-01-01\n as valid while correctly rejecting 2020-01-01 as invalid.

This is a common quirk of PHP's regex engine where $ matches a trailing newline at the end of a string unless the /D PCRE modifier is explicitly set. The trailing newline test catches this specific ecosystem gap.