timezone should be more strict according to the JSON-schema spec

[jdeniau]

The timezone of the date-time format is too lazy since #1061 has been resolved.

According to the JSON-schema specification about date-time :

Date and time format names are derived from RFC 3339, section 5.6.

and thus according to the RFC 3339:

time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset

full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset

date-time = full-date "T" full-time

particularly the time-numoffset does explicitly said that the format must include : and the time-inute

The thing that I am not sure of is the following part:

The following profile of ISO 8601 [ISO8601] dates SHOULD be used in new protocols on the Internet

Does this mean that we need to follow ISO8601 or the subset defined after this phrase ?? 🤔

Some searches about the subject:

• https://stackoverflow.com/questions/40369287/what-pattern-should-be-used-to-parse-rfc-3339-datetime-strings-in-java
• https://stackoverflow.com/questions/522251/whats-the-difference-between-iso-8601-and-rfc-3339-date-formats
• https://medium.com/easyread/understanding-about-rfc-3339-for-datetime-formatting-in-software-engineering-940aa5d5f68a

What version of Ajv are you using? Does the issue happen if you use the latest version?

Every version since #1061 has been resolved

JSON Schema

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "string",
  "format": "date-time"
}

Sample data

Should not be valid :

"2020-04-21T18:00:00+0200"

"2020-04-21T18:00:00+02"

Should be valid :

"2020-04-21T18:00:00+02:00"

Your code

const Ajv = require('ajv');

const schema = {
  $schema: 'http://json-schema.org/draft-07/schema#',
  type: 'string',
  format: 'date-time',
};

const data = '2020-04-21T18:00:00+0200';

var ajv = new Ajv();
var validate = ajv.compile(schema);
var valid = validate(data);
console.log(valid ? 'valid' : 'invalid'); // should output "invalid" but does output "valid"
if (!valid) console.log(validate.errors);

Validation result, data AFTER validation, error messages

valid

What results did you expect?

invalid

Are you going to resolve the issue?

I can if you agree with the process

[epoberezkin]

I think we should raise this question to JSON Schema and the relevant test cases could be added to JSON-Schema-Test-Suite. cc @Julian

[epoberezkin]

PR with the change: #1062 cc @cjpillsbury - what do you think?

[Julian]

I think we should raise this question to JSON Schema and the relevant test cases could be added to JSON-Schema-Test-Suite. cc @Julian

Sounds good to me!

[cjpillsbury]

@epoberezkin @Julian tldr; yeah I think we should ask JSON Schema what they think a spec-compliant implementation should do re:RFC 3339/ISO 8601.

That said, given the definitions of the specifications in question, your implementation w/the 1062 changes is spec compliant as it stands. Specifications use normative language very intentionally so, even if we interpret JSON Schema as a "new protocol on the internet" (instead of, e.g., a "schematization of pre-existing protocols actively used on the internet"), SHOULD is a (strong?) recommendation, whereas MUST is a requirement to be spec-compliant.

Some considerations:

• JSON Schema and AJV should weigh the tradeoffs in adoption and use cases based on the narrow vs. the wide interpretations of RFC 3339/ISO 8601 (Two generic common use cases that can mean the same thing but may at times be at odds are: a) schematizing actual JSON data as it is actually represented/generated by e.g. a server vs. b) constraining JSON data based on what a particular API/interface can support)
• Given the specification, we can make the current behavior in ajv configurable so that a user of AJV may choose the "narrow" ("SHOULD"/recommended) vs. the "wide" interpretation of RFC 3339, with a default of "narrow" (which reflects the spec recommendation and reduces chances of regression issues like Julian's)
• If the JSON Schema org chooses to explicitly endorse either interpretation (rather than deferring to RFC 3339), we should recommend that they update their specification to reduce ambiguity of interpretation by implementors and users of the spec.