[BUG][Javascript] Datetime parsing is producing Invalid Date on Safari

Created by: rigma

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

While using the Javascript generator to fetch date times from an API, I've stumbled upon a bug with the computing of a difference between two dates which was causing a crash when rendering components (I am using Vue.js for info, but it is not really relevant).

Strangely this issue was only produced on Safari browsers (MacOS or iOS version), because parsed date times from the API response were evaluated as Invalid Date by Safari's Javascript engine. Thus when I was computing my datetime difference a NaN value was produced.

After investigations, I've found the currently used parsing function used by the generated ApiClient class is using this static method to parse dates:

class ApiClient {

  // Generated code...

  /**
   * Parses an ISO-8601 string representation or epoch representation of a date value.
   * @param {String} str The date value as a string.
   * @returns {Date} The parsed date object.
   */
  static parseDate(str) {
    if (isNaN(str)) {
      return new Date(str.replace(/(\d)(T)(\d)/i, '$1 $3'));
    }

    return new Date(+str);
  }

  // More generated code...
}

Therefore, for an ISO 8601 formatted datetime, this method will transform the input string from YYYY-MM-DDTHH:MM:SS[+HH:MM|Z] to YYYY-MM-DD HH:MM:SS[+HH:MM|Z] (it just strip the T symbol). Those are correctly parsed on Chrome or Firefox (and I think Edge because it's based on Chromium but I haven't tested), but it is not on Safari.

I'm not sure, but I think it's because following the ECMAScript specification, a Date constructor should only accepts ISO 8601 date string or RFC 2852 timestamps and, for instance a date string like '2021-03-14 03:14:15' is not valid according to the spec. Thus I think it's for this reason Safari is returning Invalid Date for date time fields.

openapi-generator version

openapi-generator-cli 5.1.1
  commit : 560bf7e
  built  : 2021-05-07T02:32:26Z
  source : https://github.com/openapitools/openapi-generator
  docs   : https://openapi-generator.tech/

OpenAPI declaration file content or url

An API following this spec should be concerned by this issue when using a client generated with javascript-generator

Generation Details

$ openapi-generator generate \
  -i openapi.json \
  -g javascript \
  --additional-properties=usePromises=true  \
  --additional-properties=useES6=true

Steps to reproduce

1. Have a dummy API following the OpenAPI specification

openapi: "3.0.0"

components:
  responses:
    TodayResponse:
      description: A JSON object to contains today date
      content:
        application/json:
          schema:
            type: object
            properties:
              today:
                type: string
                format: date-time

paths:
  /today:
    get:
      summary: Retrieves today's date with an ISO 8601 string representation
      operationId: today
      responses:
        200:
          $ref: '#/components/responses/TodayResponse'

2. Generates a client for this API using the Javascript generator
3. The response's body today field should be evaluated to Invalid Date on Safari browsers when fetching /today path

Suggest a fix

Since a date time is defined as a data type following the RFC3339 specification in OpenAPI specification, I think it's safe to change the method rendered in the api client Mustache client by:

static parseDate(str) {
  return new Date(isNaN(str) ? str : +str);
}

But it may be safer to have a regex validating the string format and raising an exception if it's not a correctly formatted date time string.