YYYY-M-D is incorrectly allowed as a format for dates

[DJTommek]

Hi,
I'm struggling with validating "date" type. According to specifications it should be in format YYYY-MM-DD (4 digits - 2 digits - 2 digits) but this jsonschema validator is ok with YYYY-M-D.

Example schema snippet:

"d": {
    "type": "string",
    "format": "date"
}

If I test it in https://www.jsonschemavalidator.net/ it properly throws error: String '2000-1-01' does not validate against format 'date'.

I don't think that is expected behaviour.

See live demo here: https://repl.it/@TomasPalider/QueasyDrabServerapplication

I came up with workaround by combination date and regex but I don't like it since schema validation should be strict.

"d": {
    "type": "string",
    "format": "date",
    "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}$"
}

[Julian]

Sounds like a bug if so. An upstream test case would be appreciated in the upstream test suite (and of course a PR even more appreciated).

[Hubro]

I don't think this is a bug. The "date" and "time" formats were added in draft 7, and I'm guessing jsonschema.FormatChecker() doesn't default to draft 7. If you replace it with jsonschema.draft7_format_checker your example works as expected:

jsonschema.validate(data, schema, format_checker=jsonschema.draft7_format_checker)

Traceback (most recent call last):
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/jsonschema/_format.py", line 97, in check
    result = func(instance)
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/jsonschema/_format.py", line 335, in is_date
    return datetime.datetime.strptime(instance, "%Y-%m-%d")
  File "/usr/lib/python3.8/_strptime.py", line 568, in _strptime_datetime
    tt, fraction, gmtoff_fraction = _strptime(data_string, format)
  File "/usr/lib/python3.8/_strptime.py", line 349, in _strptime
    raise ValueError("time data %r does not match format %r" %
ValueError: time data '200-01-01' does not match format '%Y-%m-%d'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "main.py", line 36, in <module>
    jsonschema.validate(data, schema, format_checker=jsonschema.draft7_format_checker)
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/jsonschema/validators.py", line 934, in validate
    raise error
jsonschema.exceptions.ValidationError: '200-01-01' is not a 'date'

Failed validating 'format' in schema['properties']['d']:
    {'format': 'date', 'type': 'string'}

On instance['d']:
    '200-01-01'

[Julian]

@Hubro You're trying/showing a different example than the one reported in this ticket.

[Hubro]

@Hubro You're trying/showing a different example than the one reported in this ticket.

No, I followed his repl.it link, modified his validate line as shown, clicked run and copied that error from the output.

If I have completely misunderstood the issue then I'm still lost I'm afraid.

[DJTommek]

@Hubro See the comments in repl.it: last example will raise error as it should (that's what you posted here). But examples 2. and 3. should raise error too. Only valid example is the first one.

PS: If I understand correctly: If is used format_checker=jsonschema.FormatChecker(), it will detect schema from JSON, which is 7, right? There is no need to specify it as format_checker=jsonschema.draft7_format_checker

I already started creating some detailed tests in my fork.

[Hubro]

@DJTommek OK I see, I should have read the problem more thoroughly before responding.

[helrond]

I am experiencing this issue too, which I believe is occurring because strptime will parse dates which do not have zero-padded months or days.

I've added a PR to the upstream validation library.

I'd also be happy to submit a PR here. As I see it there are two options for replacing the current strptime implementation:

• Use the built-in fromisoformat() method on datetime.date. The drawback for this is that i t only works on Python 3.7+.
• Use a regex check (as OP did)

Any preference?

[Julian]

Awesome! Thank you very much for filing the upstream PR (I saw you already got a review there but yeah you're on the right track).

On implementation... I suppose fromisoformat is the better option, and that on 3.6 we fall back to the current (buggy) behavior.