您可以使用jsonSchemaLint进行测试。
我有这个JsonSchema,它将格式设置为“完整日期”。所有Draft-6验证器(Json.Net)都接受模式为有效。
{
"title": "MyTestSchema",
"type": "object",
"properties": {
"MyDateValue": {
"type": "string",
"format": "full-date",
"description": "We expect yyyy-MM-dd"
}
}
}
但它无法识别这个Json对象是错误的:
{
"MyDateValue": "2017-10-1"
}
当我将架构从“完整日期”切换到“日期”时,它可以工作:
{
"title": "MyTestSchema",
"type": "object",
"properties": {
"MyDateValue": {
"type": "string",
"format": "date",
"description": "We expect yyyy-MM-dd"
}
}
}
作为Json规则,最重要的一个(“完整日期”)是正确的术语吗?请参考一些文档。
答案 0 :(得分:9)
值应为date
而不是full-date
请参阅
this documentation
以下是有效值
日期时间:这应该是YYYY-MM-的ISO 8601格式的日期 DDThh:mm:UTC时间的ssZ。这是推荐的日期形式/ 时间戳。
日期:这应该是YYYY-MM-DD格式的日期。它是 建议您使用"日期时间"格式而不是" date" 除非你只需要转移日期部分。
时间:这应该是hh:mm:ss格式的时间。它是 建议您使用"日期时间"格式而不是"时间" 除非您只需要转移时间部分。
utc-millisec :这应该是差异,以 毫秒,在指定时间和午夜之间,00:00 1970年1月1日UTC。值应该是一个数字(整数或 浮动)。
来源:here
答案 1 :(得分:0)
在github here上提到这个问题,结果是可以创建自己的架构代码,并且知道验证器可能无法捕获它。
“技术上总是正确的,因为格式是可扩展的。但是,用户定义的格式将被不识别它们的验证器忽略。当然,如果其他人正在使用他们已配置识别相同的验证器名称但以不同方式对待,那么您将遇到互操作性问题。但是,对于此特定值,全日期,它取决于您的JSON模式版本。
在草案04或草案06中,全日期不是官方格式。虽然任何人将其添加为自定义格式并且没有它意味着在RFC 3339中它意味着同样的事情是要求麻烦,所以即使在那些版本中你也可以这样使用它。
在即将到来的(下周?希望?)草案07中,全日期是保留的RFC 3339格式名称空间的一部分,如果实现,必须与RFC 3339的完整日期定义兼容。草案07还将日期定义为完整日期的同义词,并建议使用日期,因为就我所知,日期在野外更为常见。
无论哪种方式,您在此处显示的这种用法可能非常安全,因为它与RFC 3339匹配,并且从草案07开始,该标准不会强制执行支持,但会强制执行,如果实施,它必须按照RFC的预期行事3339“。