-
Notifications
You must be signed in to change notification settings - Fork 434
impl GraphQLScalar for NaiveTime #657
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
Conversation
Thanks for the PR! I'm actually not sure we want to land this. One can imagine different users needing different time representations (e.g. 1:00pm vs 13:00:00, 09:15:00 vs 09:15, etc). Need to think about it some more. |
@LegNeato despite there is nothing in spec about it yet, I suppose it's naturally to follow RFC 3339 time representation for a default library scalar. If somebody needs some custom time formatting, he always can go with a custom scalar. |
Yeah, we do that for other date/time stuff. I guess it is not clear what context I'm inclined to merge this but I feel it moves Juniper to be more opinionated and less universal. Though I guess an argument can be made with |
If following an hypothetical or concrete standard is a hard constraint, then it is possible to write these "non-standard" implementations behind a feature flag, say "extra", "non-standard-impls" or "shinigamis". By doing so, you guys will take off the burden of someone that must create a wrapper and implement all by himself due to coherence rules, plus avoiding the spread of duplicated code across different projects. |
Let's put it behind a flag, off by default. Let's use the prefix |
@LegNeato Thank you |
Thanks for the PR and adding the flag and tests! |
No description provided.