Skip to content

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

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

Closed
JonAnders opened this issue Dec 16, 2016 · 21 comments
Closed

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

JonAnders opened this issue Dec 16, 2016 · 21 comments

Comments

@JonAnders
Copy link

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
Copy link

erosb commented Dec 16, 2016

I like this idea.

@epoberezkin
Copy link
Member

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

@handrews
Copy link
Contributor

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
Copy link

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
Copy link
Member

epoberezkin commented Jan 26, 2017

@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
Copy link
Contributor

@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
Copy link

@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
Copy link
Contributor

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
Copy link
Member

@handrews I agree, let's table it

@moderndeveloperllc
Copy link

@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
Copy link
Contributor

handrews commented Apr 6, 2017

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

@handrews handrews modified the milestone: draft-07 (wright-*-02) May 16, 2017
@handrews handrews changed the title Add formats "date" and "time" Add formats "date" and "time" (or all RFC 3339 formats?) Aug 20, 2017
@handrews
Copy link
Contributor

OK, so I can see three options here:

  1. Support all RFC 3339 date and time formats with the names used in the ABNF. I would write this up by changing the existing "date-time" section to a 'RFC 3339 date and time formats' section. This would reduce clutter by not re-enumerating each format.

  2. Support only "date" and "time" (alongside the existing "date-time", defined as matching "full-date" and "full-time"

  3. Do both. Reference the list of formats in RFC 3339 and define "date" and "time" as convenience aliases.

Since "format" is optional anyway, I lean towards number 3, but since format is also extensible, I don't feel super-strongly about it :-)

@moderndeveloperllc
Copy link

Number 3 would mean fewer BC breaks for existing libraries. It would also allow authors the option of parsing more formats, or just sticking with the status quo and supporting a majority of the use cases.

@adamvoss
Copy link
Contributor

Regarding 1 and 3, I am curious how much work implementers think it will be to implement all of RFC 3339? That RFC also includes less common things like durations and periods.

@handrews
Copy link
Contributor

@epoberezkin and @Julian can perhaps comment on the implementation burden. I would assume it would be deferred to some library that already implements it. It's not like it's a new cutting edge standard that no one uses yet :-D

The current guidance on formats is that if an implementation supports format at all, it SHOULD implement all of the listed formats. Which is fairly strong but not an absolute requirement.

We could also include a relatively limited set in the SHOULD, and indicate that implementations MAY support all of the RFC 3339 formats, and that any implementation that supports those format names MUST implement them in an RFC 3339-compliant way.

That would prevent actively incompatible implementations, while making the most essential one more likely to be supported.

I'm not necessarily advocating that, just brainstorming possible options.

@akuckartz
Copy link

Those interested in LD compatible solutions might want to look at ‘dcterms:W3CDTF‘

@Julian
Copy link
Member

Julian commented Aug 20, 2017 via email

@epoberezkin
Copy link
Member

@handrews There is no problem to implement, but I don't see the use case for anything but date/time. The names in https://tools.ietf.org/html/rfc3339#section-5.6 are just for ABNF - I don't really think there is a value in them as formats.

So if we add them, I would go with MAY if anything (to reserve them), not SHOULD.

Maybe add date/time in 07 and think a bit more about the rest?

@handrews
Copy link
Contributor

@epoberezkin I see your point, although I see use cases for most of them. The individual date an time pieces would be relevant for situations where these things are entered and stored individually.

For instance, at comics.org we have several fields that take year, month, and day separately, because often the complete date is not known (dodgy publishers messing with WWII-era paper rations weren't big on precise records :-) I would use date-fullyear, date-month, and date-mday were I writing a schema for that project.

partial-time is often used in context where the time zone is unimportant or known to always be the same.

I'm not saying that means we have to include all of these (although MAY for reserving is a good option), but I do see use cases from actual work that I've done for most of the names.

@handrews
Copy link
Contributor

handrews commented Sep 2, 2017

OK I think once I start looking at format (after getting Hyper-Schema as far along as I can), I am going to go with reserving the whole namespace and encouraging support with MAY, including the "date" and "time" aliases, but applying the SHOULD only to "date", "time", and "date-time".

Perhaps also a cref note in the XML that the MAY recommendation might be dropped entirely or become a SHOULD depending on what feedback, if any, we get.

While I find my own use cases fairly compelling (weird, right?), I do see @epoberezkin point. This seems like a reasonable way to split the difference and put this out in the wild to see what happens.

If @epoberezkin or anyone else thinks that's a really bad idea, do speak up.

handrews added a commit to handrews/json-schema-spec that referenced this issue Sep 8, 2017
This addresses json-schema-org#199 by supporting the two least controversial and
most requested addtional date/time formats, and reserving the
remaining namespace while we decide whether or how to specify
additional RFC 3339 formats.
@handrews
Copy link
Contributor

Merged #399.
I am probably far too amused that RFC 3339 was implemented by PR 399. I blame lack of sleep :-P

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

9 participants