Automatically serialize a non ISO date string if it is serializable by javascript date object

[pantharshit00]

Problem

Only ISO 8061 date string is automatically serialized right now.

Solution

We should allow any date string that is serializable by js Date object.

Additional context

Related: #656, #212

[matthewmueller]

Had a closer look at the user's request in #656 and talked to @timsuchanek about this.

Tim noted that we can't simply accept all dates parse-able by new Date(), because they won't take into account timezones. For example new Date("March 13") will parse but uses the system's timezone which may change between server and client. In fact, the only time we can safely parse with new Date() and will not suffer from timezone issues are ISO 8601 strings.

The problem is that we're not properly handling all types of ISO 8601, we're only handling the UTC version.

We should accept the following example formats:

2020-05-04T14:05:23Z
2020-05-04T14:05:23+00:00
2020-05-04T14:05:23+03:00
2020-05-04T14:05:23-10:00

But we only accept:

2020-05-04T14:05:23Z

[timsuchanek]

Thanks @matthewmueller I 100% agree! I think we should just add support for the missing ISO 8601 formats here, that's it.

[timsuchanek]

And that is also what I did now. You can check it out on alpha.
From now on, not only "2020-05-05T16:34:44.719Z" but also "2020-05-05T16:34:44.719+03:00" is allowed.

[joneslloyd]

I'm using a @prisma/client version of 2.0.0-previewnull-1 but when I use a Mutation like this:

mutation {
  createOneComplaint(data: {
    site: "test"
    status: "resolved"
    link: "test.com/test"
    name: "Lloyd Jones"
    publication: "Test"
    decision: "upheld"
    clause: "3"
    dateReceived: "2019-12-09T15:16:03+00:00"
    dateConcluded: "2020-01-01T09:11:34+00:00"
  }) {
    id
  }
}

I get:

"\n�[31mInvalid �[1m`prisma.complaint.create()`�[22m invocation in�[39m\n�[31m�[4m/Users/joneslloyd/Dropbox (BAY.A)/Mac/Documents/personal/development/testsite/node_modules/nexus-prisma/src/builder.ts:315:20�[24m�[39m\n\n�[2m  �[90m311 �[39m  �[38;2;107;139;140m}�[39m�[38;2;107;139;140m)�[39m�[22m\n�[2m  �[90m312 �[39m�[38;2;107;139;140m}�[39m�[22m\n�[2m  �[90m313 �[39m�[36mreturn�[39m photon�[38;2;107;139;140m[�[39mmappedField�[38;2;107;139;140m.�[39mphotonAccessor�[38;2;107;139;140m]�[39m�[38;2;107;139;140m[�[39m�[22m\n�[2m  �[90m314 �[39m  mappedField�[38;2;107;139;140m.�[39moperation�[22m\n�[31m�[1m→�[22m�[39m �[90m315 �[39m�[38;2;107;139;140m]�[39m�[38;2;107;139;140m(�[39margs\n\n\n�[31mInvalid �[1m`prisma.complaint.create()`�[22m invocation:�[39m\n\n{\n  data: {\n    site: �[2m'test'�[22m�[2m,�[22m\n�[2m�[22m    status: �[2m'resolved'�[22m�[2m,�[22m\n�[2m�[22m    link: �[2m'test.com/test'�[22m�[2m,�[22m\n�[2m�[22m    name: �[2m'Lloyd Jones'�[22m�[2m,�[22m\n�[2m�[22m    source: �[2m'Customer'�[22m�[2m,�[22m\n�[2m�[22m    decision: �[2m'upheld'�[22m�[2m,�[22m\n�[2m�[22m    clause: �[2m'3'�[22m�[2m,�[22m\n�[2m�[22m    dateReceived: �[91m'2019-12-09T15:16:03+00:00'�[39m�[2m,�[22m\n                  �[91m~~~~~~~~~~~~~~~~~~~~~~~~~~~�[39m\n�[2m�[22m    dateConcluded: �[91m'2020-01-01T09:11:34+00:00'�[39m�[2m�[22m\n                   �[91m~~~~~~~~~~~~~~~~~~~~~~~~~~~�[39m\n�[2m�[22m  }�[2m�[22m\n�[2m�[22m}\n\nArgument �[1mdateReceived�[22m: Got invalid value �[91m'2019-12-09T15:16:03+00:00'�[39m on �[1mprisma.createOneComplaint�[22m. Provided �[91mString�[39m, expected �[92mDateTime�[39m.\nArgument �[1mdateConcluded�[22m: Got invalid value �[91m'2020-01-01T09:11:34+00:00'�[39m on �[1mprisma.createOneComplaint�[22m. Provided �[91mString�[39m, expected �[92mDateTime�[39m.\n\n

A more readable version:

Provided String, expected DateTime

UPDATE:

This issue was solved thanks to the steps outlined here. So technically the issue doesn't exist, because I'm now using the alpha.