✨ Proposal: date-time format to accept those in RFC 9557

[tisonkun]

Describe the inspiration for your proposal

Currently, the "date-time" format with string type only accepts timestamp strings in RFC 3339 format. RFC 9557 is an update to RFC 3339. We may accept timestamp strings in RFC 9557 format also.

Describe the proposal

As trivial as in the inspiration. Refer to https://www.rfc-editor.org/rfc/rfc9557.html.

Describe alternatives you've considered

No response

Additional context

I encountered this issue while implementing https://github.com/GREsau/schemars/pull/364, where I tried to integrate an RFC 9557 implementation with JSON Schema definitions.

[jdesrosiers]

@gregsdennis, let's include this in the stable spec work.

[gregsdennis]

It looks like 9557 exists to allow for time zone suffixes.

2022-07-08T00:14:07+00:00[!Europe/London]
2022-07-08T00:14:07+00:00[Europe/London]

Without further indication, suffix tags are also elective. The recipient is free to ignore any suffix tag included in an IXDTF string. Reasons might include that the recipient does not implement (or know about) the specific suffix key or that it does recognize the key but cannot act on the value provided. A suffix tag may also indicate that it is critical: The recipient is advised that it MUST NOT act on the IXDTF string unless it can process the suffix tag as specified. A critical suffix tag is indicated by following its opening bracket with an exclamation mark. - Section 3.3

@json-schema-org/tsc Do we want to extend the existing date-time and time formats, or do we want to create a new format for this?

(Interestingly, .Net's DateTime type doesn't support this format, which means I'll need to write custom logic for this.

[jdesrosiers]

I think updating the current formats is fine because the changes are backwards compatible.