test(format/date-time): add hour 24 on the leap-second path as invalid

[vtushar06]

Following the methodology I used for ipv4 and uuid, I read RFC 3339 section 5.7 and found the suite tests hour 24 only on the ordinary path, not on the leap-second path.

RFC 3339 section 5.7 says "this profile of ISO 8601 only allows values between 00 and 23 for the hour". The suite has 1990-12-31T24:00:00Z (hour 24, ordinary path) and it is correctly rejected. But 2016-12-31T24:59:60+01:00 combines hour 24 with a leap second: the offset shifts it to UTC 23:59:60, which is a valid leap instant, so a validator that checks the hour bound only on the non-leap path lets the 24 through.

Changes

• Added 1 test case across draft3, draft4, draft6, draft7, draft2019-09, draft2020-12, and v1.
• 2016-12-31T24:59:60+01:00 - hour 24 on a leap-second timestamp - invalid.

Ecosystem Impact

1. ajv-formats 3.0.1 full: FAILS (accepts it). ajv checks hr <= 23 && min <= 59 only on the sec < 60 path; the sec == 60 leap branch verifies the offset-adjusted UTC time is 23:59 but never re-checks the raw hour, so 24:59:60+01:00 (UTC 23:59:60) passes with hour 24. This is the default addFormats(ajv) mode; ajv-fast rejects it.
2. python-jsonschema 4.25.1: PASSES (rejects it - no leap-second support at all).
3. sourcemeta/core is_rfc3339_datetime: PASSES (rejects it - it range-checks the hour before the leap logic).
4. Corroboration: jsonschema-rs 0.45.0, boon 0.6.1, santhosh-tekuri/jsonschema v6.0.2, and @hyperjump/json-schema 1.17.6 all reject it - ajv-formats full is the outlier.

RFC References

• RFC 3339 section 5.7 (Restrictions, hour 00-23): https://www.rfc-editor.org/rfc/rfc3339#section-5.7

Reproduction and the date-time cross-implementation matrix are in my evidence repo: https://github.com/vtushar06/JSON-Schema-format-test-Evidence/blob/main/date-time.md

Related: #965

[Copilot]

Pull request overview

This PR strengthens the JSON Schema Test Suite’s format: "date-time" coverage by adding a regression test that ensures implementations reject hour 24 even when parsing a leap-second timestamp with an offset that could normalize to a valid UTC leap instant.

Changes:

• Added a new invalid date-time case: 2016-12-31T24:59:60+01:00 (hour 24 on a leap-second path).
• Applied the same test across draft3, draft4, draft6, draft7, draft2019-09, draft2020-12, and v1.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
tests/v1/format/date-time.json	Adds the new invalid hour-24 + leap-second test for v1 date-time format coverage.
tests/draft7/optional/format/date-time.json	Adds the new invalid hour-24 + leap-second test for draft7 optional date-time format.
tests/draft6/optional/format/date-time.json	Adds the new invalid hour-24 + leap-second test for draft6 optional date-time format.
tests/draft4/optional/format/date-time.json	Adds the new invalid hour-24 + leap-second test for draft4 optional date-time format.
tests/draft3/optional/format/date-time.json	Adds the new invalid hour-24 + leap-second test for draft3 optional date-time format.
tests/draft2020-12/optional/format/date-time.json	Adds the new invalid hour-24 + leap-second test for draft2020-12 optional date-time format.
tests/draft2019-09/optional/format/date-time.json	Adds the new invalid hour-24 + leap-second test for draft2019-09 optional date-time format.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jviotti]

Looks good and spec valid as far as I can tell!