Does not conform date-time in ajv based middy validator-CodePudding

I use middy as validator package which is based on ajv, I set jsonschema like follows

    serviceDate: {
      type: 'string',
      format: 'date-time'
      },

my request is ilke this,this is basically aligned with date-time

{
"serviceDate":"2022-03-06T00:00:00"
}

But it returned following error response. I totally confused what is the wrong point of that. If someone has opinion ,please let me know. Thanks

{
    "errorMessage": "Request body validation failed: does not conform to the \"date-time\" format, is not of a type(s) number, is not of a type(s) number, is not of a type(s) number",
    "errorType": "Error",
    "offlineInfo": "If you believe this is an issue with serverless-offline please submit it, thanks. https://github.com/dherault/serverless-offline/issues",
    "stackTrace": [
        "Error: Request body validation failed: does not conform to the \"date-time\" format, is not of a type(s) number, is not of a type(s) number, is not of a type(s) number",
        "at payloadSchemaValidator (file:///Users/h.miyashita/post-pricing/packages/presentation/rest-api/shop-api/node_modules/serverless-offline/src/events/http/payloadSchemaValidator.js:7:11)",
        "at hapiHandler (file:///Users/h.miyashita/post-pricing/packages/presentation/rest-api/shop-api/node_modules/serverless-offline/src/events/http/HttpServer.js:638:11)",
        "at exports.Manager.execute (/Users/h.miyashita/post-pricing/node_modules/@hapi/hapi/lib/toolkit.js:57:29)",
        "at Object.internals.handler (/Users/h.miyashita/post-pricing/node_modules/@hapi/hapi/lib/handler.js:46:48)",
        "at exports.execute (/Users/h.miyashita/post-pricing/node_modules/@hapi/hapi/lib/handler.js:31:36)",
        "at Request._lifecycle (/Users/h.miyashita/post-pricing/node_modules/@hapi/hapi/lib/request.js:371:68)",
        "at processTicksAndRejections (node:internal/process/task_queues:95:5)"
    ]
}

I found following list which come from validation packages.I still have not found root cause of this

'date-time': /^\d{4}-(?:0[0-9]{1}|1[0-2]{1})-(3[01]|0[1-9]|[12][0-9])[tT ](2[0-4]|[01][0-9]):([0-5][0-9]):(60|[0-5][0-9])(\.\d )?([zZ]|[ -]([0-5][0-9]):(60|[0-5][0-9]))$/,
  'date': /^\d{4}-(?:0[0-9]{1}|1[0-2]{1})-(3[01]|0[1-9]|[12][0-9])$/,
  'time': /^(2[0-4]|[01][0-9]):([0-5][0-9]):(60|[0-5][0-9])$/,
  'duration': /P(T\d (H(\d M(\d S)?)?|M(\d S)?|S)|\d (D|M(\d D)?|Y(\d M(\d D)?)?)(T\d (H(\d M(\d S)?)?|M(\d S)?|S))?|\d W)/i,

CodePudding user response：

Your input "2022-03-06T00:00:00" doesn't match the date-time regex

^\d{4}-(?:0[0-9]{1}|1[0-2]{1})-(3[01]|0[1-9]|[12][0-9])[tT ](2[0-4]|[01][0-9]):([0-5][0-9]):(60|[0-5][0-9])(\.\d )?([zZ]|[ -]([0-5][0-9]):(60|[0-5][0-9]))$

It almost does. It matches this part of regex:

^\d{4}-(?:0[0-9]{1}|1[0-2]{1})-(3[01]|0[1-9]|[12][0-9])[tT ](2[0-4]|[01][0-9]):([0-5][0-9]):(60|[0-5][0-9])(\.\d )?

You are missing the other part:

([zZ]|[ -]([0-5][0-9]):(60|[0-5][0-9]))$

Which enforces you to supply a time zone. A few examples:

2022-03-06T00:00:00z
2022-03-06T00:00:00Z
2022-03-06T00:00:00 03:00