Mention support for RFC 3339 #21264
Mention support for RFC 3339 #21264
Conversation
|
Add a similar small/non-obtrusive note/link to RFC 3339 here: And here: |
| - RFC 3339 does not specify a maximum number of fractional-second digits, but specifies that at least one digit must follow the period, if a fractional-second section is present. The implementation in System.Text.Json allows up to 16 digits (to support interop with other programming languages and frameworks), but parses only the first seven. A <xref:System.Text.Json.JsonException> will be thrown if there are more than 16 fractional second digits when reading `DateTime` and `DateTimeOffset` instances. | ||
| - RFC 3339 allows the "T" and "Z" characters to be "t" or "z" respectively, but allows applications to limit support to just the upper-case variants. The implementation in System.Text.Json requires them to be "T" and "Z". A <xref:System.Text.Json.JsonException> will be thrown if input payloads contain "t" or "z" when reading `DateTime` and `DateTimeOffset` instances. | ||
| - RFC 3339 specifies that the date and time sections are separated by "T", but allows applications to separate them by a space (" ") instead. System.Text.Json requires date and time sections to be separated with "T". A <xref:System.Text.Json.JsonException> will be thrown if input payloads contain a space (" ") when reading `DateTime` and `DateTimeOffset` instances. |
There was a problem hiding this comment.
Awesome!
Does RFC 3339 allow space to be disallowed, just like lower case t/z?
There was a problem hiding this comment.
Hmm
ISO 8601 defines date and time separated by "T".
Applications using this syntax may choose, for the sake of
readability, to specify a full-date and full-time separated by
(say) a space character.
I interpret this to mean that applications can emit it, but it doesn't explicitly say that applications have to be able to parse it.
We can always add support for this if it becomes a problem.
There was a problem hiding this comment.
Makes sense. Thanks.
We can always add support for this if it becomes a problem.
That is a good stance to have for the time being, and we are also clearly documenting it now if someone needs to know.
Can we add the links to these other docs too? Or maybe, cross-link to our DateTime concept doc to increase its visibility/discoverability. We want folks to be able to understand if and how well our DateTime serialization support fits with ISO 8601 and RFC 3339. |
4 participants
No description provided.