-
Notifications
You must be signed in to change notification settings - Fork 163
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
Spec and docs should refer to the serialization format as RFC 9557, not ISO 8601 #3071
Comments
I think we can do exactly that in colloquial text, certainly in the docs and cookbook. Although we'll have to take care that that doesn't raise the question "so this means I can't pass an ISO string anymore?" Formally, the string format is ISO 8601 with certain optional things allowed or disallowed "by mutual agreement of the communicating parties" and with extensions given by RFC 9557. So it might not make sense to call them "RFC 9557" strings everywhere in the spec. |
@ptomato Not sure this is correct. The string annotations for time zones and calendars are not part of ISO 8601 but are part of RFC 9557. |
You're right, of course 😄 What I meant to say was that even without the RFC 9557 annotations, there are optional ISO 8601 things that are allowed "by mutual agreement", like 6-digit extended years. Straight-up RFC 9557 strings would be RFC 3339 strings plus RFC 9557 annotations, and RFC 3339 does not define some optional ISO 8601 things like 6-digit extended years. |
Mostly in docs, but also in error messages, comments, etc., and in some cases in the prose parts of the spec text. In some cases phrased to keep in mind that ISO 8601 probably has better name recognition for the time being. Closes: #3071
Seems like we should be explicit in the spec in how we extend RFC 9557. But I like treating that as the base rather than ISO 8601 which lacks the annotations which are arguably more important to Temporal than edge cases like 6-digit years. |
Mostly in docs, but also in error messages, comments, etc., and in some cases in the prose parts of the spec text. In some cases phrased to keep in mind that ISO 8601 probably has better name recognition for the time being. Closes: #3071
Seems reasonable, got a suggestion over at #3073? |
Thanks! I left a bunch of suggestions on that commit. |
Mostly in docs, but also in error messages, comments, etc., and in some cases in the prose parts of the spec text. In some cases phrased to keep in mind that ISO 8601 probably has better name recognition for the time being. Closes: #3071
Following mdn/content#37344: the spec and docs make zero mentions of RFC 9557 and refer to the serialization format, even in the presence of annotations, as ISO 8601, which is potentially confusing. Since RFC 9557 is standardized, we can refer to it for the string format.
...and more.
The text was updated successfully, but these errors were encountered: