Specification section
Validation Specification (Draft 2020-12), Section 7.3.1. Dates and Times
What is unclear?
While exhaustively documenting the date-time format tests for the JSON Schema Test Suite , I noticed a slight ambiguity in how JSON Schema references RFC 3339.
During my previous PR (840 in Json schema test suite), @jdesrosiers established the clear baseline that the test suite must be "100% aligned with the spec" rather than relying on practical implementation heuristics. Applying that strict mathematical lens to date-time brings up a conflict.
Currently, JSON Schema Draft 2020-12 (Section 7.3.1) states:
"A string instance is valid against this attribute if it is a valid representation according to the "date-time" production in RFC 3339 [RFC3339] section 5.6."
However, under strict ABNF parsing rules, anything following a ; is treated as a comment. If we look at the productions in RFC 3339 §5.6:
date-month = 2DIGIT ; 01-12
time-hour = 2DIGIT ; 00-23
Mathematically, the structural rule for these components is simply 2DIGIT (e.g., hour = 99 is structurally valid under §5.6). The actual calendar limits (hours 00-23, leap year calculations, etc.) are enforced exclusively in the prose of Section 5.7 ("Restrictions").
Because Draft 2020-12 explicitly cites only §5.6, it creates a technical loophole where a strict validator could ignore calendar limits and still claim 100% literal spec compliance.
Also, when documenting these cases in the JSON Test Suite comments, should I cite only §5.6 (to strictly match the current JSON Schema text), or should I explicitly cite both §5.6 and §5.7 (to clarify the actual source of the restriction for future implementers)?
(Note: @jviotti and I agree that the §5.7 semantic restrictions do apply for the test suite's purposes, but the spec text itself currently leaves this ambiguous for implementers)
Proposal
Update the specification text in future drafts to explicitly require compliance with the restrictions in RFC 3339 Section 5.7.
For example, the text could be modified to something like:
"A string instance is valid against this attribute if it is a valid representation according to the "date-time" production in RFC 3339 [RFC3339] section 5.6 and satisfies the restrictions defined in section 5.7."
This explicit inclusion will ensure future validator implementers and test suite authors don't have to guess whether calendar math is implicitly required when only the grammar section is cited.
Do you think this work might require an [Architectural Decision Record (ADR)]? (significant or noteworthy)
No
Specification section
Validation Specification (Draft 2020-12), Section 7.3.1. Dates and Times
What is unclear?
While exhaustively documenting the
date-timeformat tests for the JSON Schema Test Suite , I noticed a slight ambiguity in how JSON Schema references RFC 3339.During my previous PR (840 in Json schema test suite), @jdesrosiers established the clear baseline that the test suite must be "100% aligned with the spec" rather than relying on practical implementation heuristics. Applying that strict mathematical lens to
date-timebrings up a conflict.Currently, JSON Schema Draft 2020-12 (Section 7.3.1) states:
However, under strict ABNF parsing rules, anything following a
;is treated as a comment. If we look at the productions in RFC 3339 §5.6:Mathematically, the structural rule for these components is simply 2DIGIT (e.g., hour = 99 is structurally valid under §5.6). The actual calendar limits (hours 00-23, leap year calculations, etc.) are enforced exclusively in the prose of Section 5.7 ("Restrictions").
Because Draft 2020-12 explicitly cites only §5.6, it creates a technical loophole where a strict validator could ignore calendar limits and still claim 100% literal spec compliance.
Also, when documenting these cases in the JSON Test Suite comments, should I cite only §5.6 (to strictly match the current JSON Schema text), or should I explicitly cite both §5.6 and §5.7 (to clarify the actual source of the restriction for future implementers)?
(Note: @jviotti and I agree that the §5.7 semantic restrictions do apply for the test suite's purposes, but the spec text itself currently leaves this ambiguous for implementers)
Proposal
Update the specification text in future drafts to explicitly require compliance with the restrictions in RFC 3339 Section 5.7.
For example, the text could be modified to something like:
This explicit inclusion will ensure future validator implementers and test suite authors don't have to guess whether calendar math is implicitly required when only the grammar section is cited.
Do you think this work might require an [Architectural Decision Record (ADR)]? (significant or noteworthy)
No