We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I assume this is related to #380
After updating to 1.2.1 from 1.1.5 I'm receiving this error: DateTime cannot represent an invalid date-time-string 2020-06-01T10:02:00+0000.
DateTime cannot represent an invalid date-time-string 2020-06-01T10:02:00+0000.
I see that https://github.com/Urigo/graphql-scalars/blob/master/src/scalars/iso-date/validator.ts#L120 validation fails because my TZ is missing : (my backend is using RFC822 format); Javascript Date.parse() seems to be fine about it:
:
Date.parse()
Date.parse("2020-06-05T09:37:00+0000") 1591349820000 Date.parse("2020-06-05T09:37:00+00:00") 1591349820000
In the previous version, the serializer "coerced" the non-iso input into a valid output, but this apparently is not the case anymore.
What is the expected way of handling DateTimes? Do I have to convert the date in the RFC3339-ISO8601 format in my resolvers?
(PS: Release notes are missing for 1.1.8 onward)
The text was updated successfully, but these errors were encountered:
Same issue here. I've locked to 1.1.5
Sorry, something went wrong.
Less strict DateTime scalar #395
449e96a
The old behavior is available in 1.2.6!
Less strict DateTime scalar Urigo#395
26e7cc7
No branches or pull requests
I assume this is related to #380
After updating to 1.2.1 from 1.1.5 I'm receiving this error:
DateTime cannot represent an invalid date-time-string 2020-06-01T10:02:00+0000.
I see that https://github.com/Urigo/graphql-scalars/blob/master/src/scalars/iso-date/validator.ts#L120 validation fails because my TZ is missing
:
(my backend is using RFC822 format); JavascriptDate.parse()
seems to be fine about it:In the previous version, the serializer "coerced" the non-iso input into a valid output, but this apparently is not the case anymore.
What is the expected way of handling DateTimes? Do I have to convert the date in the RFC3339-ISO8601 format in my resolvers?
(PS: Release notes are missing for 1.1.8 onward)
The text was updated successfully, but these errors were encountered: