-
-
Notifications
You must be signed in to change notification settings - Fork 753
New issue
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
DateTime type does not follow its own specification #6887
Comments
This is mistakenly labelled |
This is improved in 14.0.0-rc.0, but there is still not perfect overlap with the valid/invalid patterns in https://www.graphql-scalars.com/date-time. |
It's about the requirement of exactly three digits millisecond part. The value |
Additionally, the spec page lists (I have raised an issue about that on the spec repo: andimarek/graphql-scalars.com#13) |
This is intentional:
We felt that requiring a fixed 3 fractional digits was unnecessarily arbitrary, and inconsistent with RFC 3339. We made fractional seconds optional (as they are in RFC 3339), but decided to limit them to 7, as most languages support 7 or fewer digits of precision. An issue has been raised before regarding the number and requirement for fractional seconds. It's not ideal to have this "specified by" URL pointing to a specification that isn't a 100% match, but Michael did mention that he may discuss this with Andi. Regardless, I'll add a note to the documentation about this difference next week. |
Thanks for the clarification! Feel free to close this issue. |
Product
Hot Chocolate
Version
13.8.1
Link to minimal reproduction
See zip below
Steps to reproduce
Repro solution: HotChocolateBugRepro.zip
Relevant code:
When using
DateTimeOffset
, the schema contains this:The spec on that URL gives examples of valid and invalid strings. Currently, HotChocolate accepts half of the invalid patterns, and more. This includes for example a date only (where the time will be taken to be midnight in the server's time zone, which is bad and can easily cause bugs and confusion for API clients - ask me how I know...).
It also accepts formats such as
2010/02/11
and11.02.2010
(at least on my computer with my regional settings).HotChocolate needs to be much stricter if it is to actually represent the linked
DateTime
type.Note that this may be relevant for other of HotChocolate's built-in scalars, too. (I haven't checked, but I assume it applies to at least
DateTime
).What is expected?
Parsing conforms to the linked spec.
What is actually happening?
Parsing is much more lenient than the linked spec and accepts invalid input.
Relevant log output
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: