You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While any is great, a set of narrower types might be useful:
anyobject
anyarray
anyprimitive
Also, the data and time types are based on RFC 3339, which is itself based on ISO 8601. It would be useful to have some ISO 8601 types since most implemenations will use ISO 8601 to do RFC 3339 validation:
iso8601date
iso8601time
iso8601datetime
The text was updated successfully, but these errors were encountered:
But I'm not seeing that we need the iso8601* types. As you say, RFC 3339 is a subset of ISO 8601, and I believe - for good reason. Having pure, unconstrained ISO 8601 types could open a whole can of worms.
My feeling is that we should limit the times to the RFC 3339 subset, (as we have now), and if someone wants to use a full ISO 8601 engine to manipulate that subset, then that's an implementation detail for them.
For information, XML Schema (part 2 https://www.w3.org/TR/xmlschema11-2/#date ) is essentially RFC 3339, but allows more than 4 digits of year, and negative years. That maybe helpful for publishing etc., but not sure it helps with IETF type things.
But if you want some JSON to describe, say, the periods covered by history books, including the ancient Egyptians, the going beyond RFC 3339 could be useful.
This is a proposal for new types.
While
any
is great, a set of narrower types might be useful:Also, the data and time types are based on RFC 3339, which is itself based on ISO 8601. It would be useful to have some ISO 8601 types since most implemenations will use ISO 8601 to do RFC 3339 validation:
The text was updated successfully, but these errors were encountered: