Skip to content
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

feat: Add support for the time crate #1006

Merged
merged 8 commits into from
Dec 16, 2021

Conversation

scott-wilson
Copy link
Contributor

This adds support for the time crate due to concerns with safety in the chrono crate (see rustsec/advisory-db#1082).

So, I added support for time, since it looks like that might become the "preferred" date/time crate in the future.

@tyranron tyranron added enhancement Improvement of existing features or bugfix k::integration Related to integration with third-party libraries or systems labels Dec 16, 2021
@tyranron tyranron self-requested a review December 16, 2021 17:05
Copy link
Member

@tyranron tyranron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@scott-wilson thank you for bringing this up and putting effort into implementing this.

However, now it's quite a mess with our scalar types regarding date and time. While chrono provides DateTimeFixedOffset, DateTimeUtc and bunch of Naive* stuff, this time integration diverges in naming, and now we have PrimitiveDateTime and the others. This definitely begs for some standartization, and, fortunately, we have GraphQL Scalars for that.

I've adjusted your implementation to map time types to the appropriate scalars from GraphQL Scalars collection:

Rust type Format GraphQL scalar
Date yyyy-MM-dd Date
Time HH:mm[:ss[.SSS]] LocalTime
PrimitiveDateTime yyyy-MM-dd HH:mm:ss LocalDateTime
OffsetDateTime RFC 3339 string DateTime
UtcOffset ±hh:mm UtcOffset

I'd like also to integrade Duration from time, but it lacks parsing required by Duration scalar.

@ilslv we need to do the similar adjusting for chrono types in a separate PR.

| `Date` | YYYY-MM-DD | |
| `PrimitiveDateTime` | YYYY-MM-DD HH-MM-SS | |
| `Time` | H:M:S | Optional. Use the `scalar-naivetime` |
| | | feature. |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's prety standard one. I guess we can go without additional feature here.

{
fn resolve(&self) -> Value {
let description =
parse("[year]-[month]-[day]").expect("Failed to parse format description");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doing format parsing every time is not quite performance wise. We better use Lazy here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, we do actually have const one.

@scott-wilson
Copy link
Contributor Author

I was just about to take a look at the two notes, and it looks like you already tackled that, thanks!

Anything you need me to polish up?

@tyranron
Copy link
Member

@scott-wilson it's approved, I'm about to merge this PR.

Thanks again! 🍻

@tyranron tyranron merged commit 3e4d4ea into graphql-rust:master Dec 16, 2021
tyranron added a commit that referenced this pull request Dec 20, 2021
- fix input/result coercions for `OffsetDateTime` according to spec
- use `@specifyByUrl` directive
- remove `time` from default features
@tyranron tyranron added this to the 0.16.0 milestone Apr 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement of existing features or bugfix k::integration Related to integration with third-party libraries or systems
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants