date-time format validation regex is invalid
matrousse opened this issue · comments
JSON Schema validation specification refers to rfc3339 chapter 5.6
This sample date-time value : 2014-03-11T00:00:00.000+01:00 is rejected by revalidator and it should not.
I propose the following modification of the regex from
/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:.\d{1,3})?Z$/
to
/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:\.\d{1,3})?((?:[\+\-]\d{2}:\d{2})|Z)$/
Note that this proposition also include a fix where the . separator for millisecond could be replaced by any character.
In the context of Javascript (new Date).toJSON() always ends with Z, so I don't think the behavior should change.
Baseline of revalidator is : "Revalidator has JSONSchema compatibility as primary goal."
Therefore, limiting date validation to Javascript default behavior is too much restrictive. In my case, the JSON to validate was generated from java library.
You're right. Still, I don't think a single format should have multiple possible strings. Think about places that expect date/time in UTC - if you allow date-time to mean both Z and offset suffixes you must introduce another check. So maybe date-time-offset would be more appropriate than overloading the existing date-time?
In any case this project seems to be somewhat unmaintained so I'll fork it and work on most of the issues when I get a chance since I'm actually using it in production.
My proposition checks both case: see |Z)$ at the end of the regexp
That's the problem. It's not deterministic. If I have a function or a system that expects date/time to be in UTC format that ends with a Z (as opposed to +00:00) then an expression may validate but not be recognizable. Modifying an existing format may cause undefined behavior in apps.