-
-
Notifications
You must be signed in to change notification settings - Fork 321
incorporate RFC 9557 time zone extension into 'date-time' format #1609
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
base: main
Are you sure you want to change the base?
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.
valid representation according to the "date-time" ABNF rule in RFC 3339, | ||
optionally with the "time-zone" rule in RFC 9557 |
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:
valid representation according to the "date-time" ABNF rule in RFC 3339, | |
optionally with the "time-zone" rule in RFC 9557 | |
valid representation of the "date-time" ABNF rule in RFC 3339 or such a | |
string that is immediately followed by a valid representation of the | |
"time-zone" rule in RFC 9557 |
- *duration*: A string instance is valid against this attribute if it is a valid | ||
representation according to the "duration" ABNF rule (referenced above) | ||
representation according to the "duration" ABNF rule in ISO 8601 |
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.
ISO 8601 does not use ABNF, or have "rules" as such.
representation according to the "duration" ABNF rule in ISO 8601 | |
representation according to the "duration" ABNF rule in RFC 3339 Appendix A |
@@ -397,22 +397,24 @@ custom format values. | |||
These attributes apply to string instances. | |||
|
|||
Date and time format names are derived from | |||
[RFC 9557, section 4.1](https://www.rfc-editor.org/info/rfc9557) which extends | |||
[RFC 3339, section 5.6](https://www.rfc-editor.org/info/rfc3339). The duration | |||
format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339. |
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.
format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339. | |
format is from ISO 8601 as formalized into ABNF by RFC 3339 Appendix A. |
Yeah, I read that the update to |
I don't consider this a breaking change because |
What kind of change does this PR introduce?
Enhancement
Issue & Discussion References
Summary
Extends the
date-time
format by incorporating time zone information from RFC 9557.Does this PR introduce a breaking change?
NoYes?date-time
strings that would have previously failed would now pass.