-
-
Notifications
You must be signed in to change notification settings - Fork 352
incorporate RFC 9557 time zone extension into 'date-time' format #1609
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Isn't this a breaking change, if strings that were invalid before are now considered valid?
That's what I was thinking, too. Someone mentioned it wasn't, and I failed to research it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this would be a breaking change.
Additionally, note we specify the duration format from ISO 8601 as per RFC 3339 Appendix A.
RFC 3339 Appendix A notes...
This information is based on the 1988 version of ISO 8601. There may
be some changes in the 2000 revision.
I'm positive we discussed before and opted to not reference ISO directly because of the paywall nature of the standard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments from someone familiar with RFC 3339, RFC 9557, and ISO 8601.
specs/jsonschema-validation.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This text is not clear to me... is the intent to allow a subset of the RFC 9557 grammar that includes time-zone but not suffix-tag? If so, I think that should be more explicit:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes, I see. I had stopped in that block in 9557 at time-zone and didn't continue on to see suffix. That should certainly be included.
I think what we're looking for here is date-time-ext, except that suffix is optional. I'll update this.
Yeah, I read that the update to date-time has not changed the syntax, the only update around date-time is to align Z with the common usage of "no time zone".
Isn't this a breaking change, if strings that were invalid before are now considered valid?
I don't consider this a breaking change because format allows partial validation. If strict validation was required, it would be a different story. Every value that passed in 2020-12 would still pass with these changes. I think this change just makes what was previously considered a strict validation implementation into a partial validation implementation.
I don't consider this a breaking change because format allows partial validation.
Fair enough. We could mention this explicitly in the spec either in the section where we talk about breaking changes, or right when formats are introduced -- that formats may in the future change to use updated RFCs that cover the same kind of content. (e.g. when RFC3986 is obsoleted, we'll want to move to the new version of that too.)
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
Uh oh!
There was an error while loading. Please reload this page.
What kind of change does this PR introduce?
Enhancement
Issue & Discussion References
Summary
Extends the
date-timeformat by incorporating time zone information from RFC 9557.Does this PR introduce a breaking change?
(削除) No (削除ここまで)Yes?date-timestrings that would have previously failed would now pass.