Skip to content

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

gregsdennis
Copy link
Member

@gregsdennis gregsdennis commented Jun 21, 2025

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?

No Yes? date-time strings that would have previously failed would now pass.

@karenetheridge
Copy link
Member

Isn't this a breaking change, if strings that were invalid before are now considered valid?

@gregsdennis
Copy link
Member Author

That's what I was thinking, too. Someone mentioned it wasn't, and I failed to research it.

Copy link
Member

@Relequestual Relequestual left a 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.

Copy link
Contributor

@gibson042 gibson042 left a 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.

Comment on lines +405 to +406
valid representation according to the "date-time" ABNF rule in RFC 3339,
optionally with the "time-zone" rule in RFC 9557
Copy link
Contributor

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:

Suggested change
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
Copy link
Contributor

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.

Suggested change
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

@awwright
Copy link
Member

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".

@jdesrosiers
Copy link
Member

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

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