Normalize optional/format/date-time, improve leap seconds tests.

[ChALkeR]

1. First commit copies an invalid closing Z after time-zone offset testcase from draft6 to draft2019-09, draft2020-12, draft7, draft4, draft-future where it was missing.
2. Second commit adds two separate valid tests for leap seconds (like in optional/format/time).
3. And also removes leap seconds from a invalid day in date-time string and an invalid offset in date-time string tests to ensure that they fail because of those reasons and not because of a leap second.

Note that while this uses a valid leap second date (1998-12-31, which is stated explicitly in RFC 3339, Appendix D) this doesn't test that the validator actually has a list of valid leap seconds and not just verifies the shape per RFC 3339. I.e. there is no test that should fail because of invalid date/leap second combo, as leap seconds come from an external data source and might be introduced later. Even checking that they are in ****-12-31 or ****-06-31 is invalid, as that might be changed in the data source and is not a hard requirement.

Refs:

• https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-7.3.1
• https://datatracker.ietf.org/doc/html/rfc3339
• https://datatracker.ietf.org/doc/html/rfc3339#appendix-D

[karenetheridge]

please request reviews of the team, not just me. I am just one cat!

[ChALkeR]

@karenetheridge I also requested the team review above ).
Ok, I'll use just that for the future PRs, thanks!

[karenetheridge]

this looks good to me -- it just needs a rebase with master as there are some conflicts there. thanks!

[karenetheridge]

actually -- can you add an invalid leap second test too? say "1998-12-30T23:59:60Z" (one day before the real leap second), to check that implementations don't just accept 23:59:60 for every day.

[ChALkeR]

@karenetheridge Rebased.

Re: tests for invalid leap seconds — see the PR description, I'm not convinced yet that it's a good idea to add those.

The referenced spec doesn't maintain a list of leap seconds and instead points to an external resource for that in an appendix.
Also there is no restriction demanding that leap seconds should be only in June/December, even though to date they were.

The grammar element time-second may have the value "60" at the end of
months in which a leap second occurs -- to date: June (XXXX-06-
30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix D for
a table of leap seconds. It is also possible for a leap second to be
subtracted, at which times the maximum value of time-second is "58".
At all other times the maximum value of time-second is "59".
Further, in time zones other than "Z", the leap second point is
shifted by the zone offset (so it happens at the same instant around
the globe).

Leap seconds cannot be predicted far into the future. The
International Earth Rotation Service publishes bulletins [IERS] that
announce leap seconds with a few weeks' warning. Applications should
not generate timestamps involving inserted leap seconds until after
the leap seconds are announced.

I think given that the spec is more complex on that, we can handle that in a separate PR if desired.

[ChALkeR]

@karenetheridge I added a test that verifies that :61 is invalid though, to filter out impls simply checking for \d\d or [0-6]\d there.

time format already has a test for that, so this is just symmetrical.

[karenetheridge]

Right, no date/time parser should ever be assuming what leap seconds are going to exist in the future, since indeed the rules for determining when they exist are not predictable and depends on astronomical observations. :)

So this comes down to "how picky do we really want to be", which has been the case for so many other formats :). Some implementations may find it easy to verify whether a particular timestamp in the past is indeed a valid leap second or not (by using a lookup table that is available to it), and others may not. We do consider dates like "2001-02-31" to be invalid, even though it is syntactically correct, because we know that the month of February can never have 31 days. There's also a rule that leap seconds can only be added to the last second of a day (therefore 23:59:60 might be a valid leap second, but 22:58:60 can never be valid). It's just "which days" that's the tricky part.

tldr: IMO, If there's doubt, best to leave it out (i.e. not have a valid or invalid test for that case).

[ChALkeR]

@karenetheridge

tldr: IMO, If there's doubt, best to leave it out (i.e. not have a valid or invalid test for that case).

Yeah, let's at least keep that out of this PR. :-)

but 22:58:60 can never be valid

Ah, that's a good one. Added it (and for the wrong hour).
Those are also already present in time tests, just date-time has been missing those.

Does this LGTY?

[karenetheridge]

yes, this LGTM!