Add formats "date" and "time" (or all RFC 3339 formats?)

[JonAnders]

The current draft specifies "date-time" as a format attribute. A related and very useful extension of this would be to add "date" and "time" separately as well. These would be defined as the "full-date" and "full-time" specified in RFC 3339 section 5.6, the same section as where the "date-time" format is specified.

The "date" and "time" formats were part of the original draft, but were removed in draft v4. This comment by author of draft v4 however, seems to indicate that these shouldn't have been removed and should be re-introduced: java-json-tools/json-schema-validator#103 (comment)

Just to be clear, I don't believe the list of supported formats should be a huge list of every thinkable format that might be useful for someone. But I think that the three formats of "date", "time" and "date-time" are so closely related that either all of them should be supported or none.

Also, implementing "date" and "time" should be a small task for implementers of validators, especially if the "date-time" format is already supported.

[erosb]

I like this idea.

[epoberezkin]

many validators already support them btw, so adding to spec is a good idea

[handrews]

I am also in favor. I want to avoid format proliferation, but completing the logical sets of things that are already in format (e.g. from the same RFCs like these from RFC 3339 or that are used in JSON Schema itself like "jsonpointer" and "uritemplate") seems like a good idea.

And @epoberezkin's point about existing support is a very strong indicator of utility.

[moderndeveloperllc]

I would suggest that perhaps the full format list in Section 5.6 be included to bring the draft into congruency with the RFC.

[epoberezkin]

@moderndeveloperllc it seems a bit overkill, it's 12 things most of which exist primarily for ABNF rather than having individual value... Also I think consistency with the existing usage practice ("date" and "time" rather than "full-date" and "full-time") is more important.

@handrews I actually thought "date" and "time" would be in draft-06 but I guess they were out of scope. There is no rush to include them given an optional nature of format, we can stabilise formats in the next draft.

[handrews]

@epoberezkin I considered it but didn't want to delay Draft 06 with a debate on how many of the RFC formats to put in :-)

If @awwright is OK with throwing in "date" and "time" (matching "full-date" and "full-time" respectively) then I'd be fine with that. If we don't have consensus on which formats to add, I'd rather work it out for the next draft. We're very close to finishing draft 06 and I really don't want to delay it further.

[moderndeveloperllc]

@epoberezkin Unfortunately if you start deviating from the naming conventions, you run into the case where the draft only vaguely follows the RFC, as it doesn't include all the formats, and renames a few of them. This could cause more confusion than a handful of extra formats.

If @awwright doesn't think it prudent to stick with full-date and full-time, I would suggest removing the reference to RFC 3339 entirely and specifying the formats directly. That would allow using whatever format names desired without causing confusion by referencing an RFC that's only partially adhered to.

[handrews]

I don't have a particularly strong opinion about the "full-" prefix. I think there are too many possibilities here to resolve within the next few days, so I think this is for Draft 07, not 06.

[epoberezkin]

@handrews I agree, let's table it

[moderndeveloperllc]

@handrews Do you know of a roadmap for when 07 items will be reconsidered :-) FWIW, I've started to come around to the idea of just date and time without the prefix. Most validators I've checked out use those - if they do anything other than date-time. This is especially prevalent on the JS form builders I've seen as it makes it more straightforward to generate HTML5 tags from schema.

[handrews]

@moderndeveloperllc we've been focusing on resolving some things with Hyper-Schema to get draft-06 out the door. There is only one PR still open for that so hopefully the draft will get published by next week and we can start working on draft-07.