test(format/date-time): add timezone offset boundary and leap second cases

[AcEKaycgR]

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

Adds 8 new cases asserting strict timezone offset formatting, floor/ceiling bounds, and IERS leap second compliance in the date-time format.

Added:

• UTC numeric offset +00:00 (valid)
• Negative zero offset -00:00 (valid)
• Maximum positive offset +23:59 (valid)
• Maximum negative offset -23:59 (valid)
• Out-of-bounds offset hour +24:00 (invalid)
• Z followed by numeric offset Z+00:00 (invalid)
• Valid leap second on another confirmed IERS date 2016 (valid)
• Leap second with offset producing wrong UTC (invalid)

Ecosystem Impact (Triangulation):

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

1. PHP Bug Caught: php-opis-json-schema incorrectly validates the invalid leap second with non-UTC offset ("1998-12-31T23:59:60+01:00") as valid (expected invalid), failing to assert that leap seconds can only align with UTC midnight.
2. Go Bug Caught: go-gojsonschema incorrectly validates the valid leap second "2016-12-31T23:59:60Z" as invalid due to Go standard runtime limitations on leap second support.

@jviotti @jdesrosiers @karenetheridge Ready for review.

[jviotti]

Looks good to me

[vtushar06]

@AcEKaycgR I checked the verdicts against section 5.6 (time-numoffset) and 5.7. Same note as on the other two splits about the bar, most of these don't split a validator, so it would help to note which implementation each one trips. Two specifics, with what I found running them:

• +24:00 only trips ajv fast - ajv-full and python both reject it correctly. The stronger, same-category case is 1985-04-12T23:20:50+01 (offset with no minutes): ajv-formats full (the default addFormats(ajv)) accepts it, because its offset group (?::?(\d\d))? makes the whole minute component optional. That's the one that breaks the default config - I opened it as test(format/date-time): add numeric offset without minutes as invalid #960.
• On the leap side, 2016-12-31T24:59:60+01:00 (hour 24 on a leap-second timestamp) is accepted by ajv-full: it checks hr <= 23 only on the non-leap path, and the leap branch only verifies the offset lands on UTC 23:59, never re-checking the raw hour. None of the leap tests here keep hour > 23, so that path is untested - I opened it as test(format/date-time): add hour 24 on the leap-second path as invalid #961.
• 2016-12-31T23:59:60Z is the same "python has no leap-second support" mechanism as the existing 1998-12-31T23:59:60Z valid-leap test, so in effect it is a duplicate.

These eight inputs are also all in your #891, we can close that one once we're ready with this.

[AcEKaycgR]

Hi @vtushar06,

Thanks for pointing that out. I have removed the duplicate 2016 leap second case "2016-12-31T23:59:60Z" to keep the PR clean.

I also noticed you have already opened separate PRs (#960 and #961) for the other offset minutes and leap second hour boundaries you found.