Update chrono scalars according to the graphql-scalars.dev

[ilslv]

Revealed from #1006 (review)

Synopsis

For now scalars from time and chrono crates are different.

Solution

Update chrono scalars according to the graphql-scalars.dev

Checklist

• Created PR:
  • In draft mode
  • Name contains Draft: prefix
  • Name contains issue reference
  • Has assignee
• Documentation is updated (if required)
• Tests are updated (if required)
• Changes conform code style
• CHANGELOG entry is added (if required)
• FCM (final commit message) is posted
  • and approved
• Review is completed and changes are approved
• Before merge:
  • Milestone is set
  • PR's name and description are correct and up-to-date
  • Draft: prefix is removed
  • All temporary labels are removed

[ilslv]

FCM

Update `chrono` scalars according to the `graphql-scalars.dev` (#1010)

- remove `scalar-naivetime` feature

[tyranron]

What we do really want here is

impl<S: ScalarValue, Tz: TimeZone> GraphQLScalar for DateTime<Tz>

but #[graphql_scalar] macro doesn't allows us to make generic impls.

So, let's first rewrite #[graphql_scalar] so we can do that.

Another problem arosen here is that chrono is very bad at relations between TimeZones. We have no relations like (From) between Utc, FixedOffset and Local, and the only thing how we can create Tz: TimeZone is TimeZone::from_offset(), where Offset is another generic parameter.

So we should write up some FromUtcOffset (or similar) machinery here, to wire them up, so, after parsing DateTime<FixedOffset> we can convert it into arbitrary DateTime<Tz>.

[ilslv]

@tyranron

So we should write up some FromUtcOffset (or similar) machinery here, to wire them up, so, after parsing DateTime<FixedOffset> we can convert it into arbitrary DateTime<Tz>.

All in all the main problem is that to convert into arbitrary DateTime<Tz> you need an instance of a type, not just type itself. So even with custom machinery we can support only FixedOffset and Utc. chrono-tz on the other hand, uses big enum instead of separate types to represent all timezones, so our users will have to implement needed timezones manually even to use them as outputs.

I propose different approach: we allow only DateTime<Utc> and DateTime<FixedOffsets> as inputs, while any DateTime<Tz> as output. So usage will look something like that:

#[graphql_object]
impl QueryRoot {
    fn transform(input: DateTime<Utc>) -> DateTime<chrono_tz::Tz> {
        input.with_timezone(&chrono_tz::CET)
    }
}

The only downside is that we won't be able to use macros to implement scalar and fallback to manual implementation. This happens because with don't have a mechanism to enforce different trait bounds on different resolvers.

UPD: it's wasn't so easy, as I expected, as trait bound are tightly coupled together. I'm investigating whether we can have different trait bounds on serialisation/deserialisation on the same scalar type.

UPD2: The main problem is with storing scalars in registry:

impl<'r, S: 'r> Registry<'r, S> {
    /// Creates a [`ScalarMeta`] type.
    pub fn build_scalar_type<T>(&mut self, info: &T::TypeInfo) -> ScalarMeta<'r, S>
    where
        T: GraphQLType<S> + FromInputValue<S> + ParseScalarValue<S>,
        T::Error: IntoFieldError<S>,
        S: ScalarValue,
    {
        let name = T::name(info).expect("Scalar types must be named. Implement `name()`");

        ScalarMeta::new::<T>(Cow::Owned(name.to_string()))
    }
}

Those trait bounds are reasonable, but enforce same trait bounds on both serialisation and deserialisation.

[tyranron]

I think we should update chrono-tz integration as well inside this PR.

[tyranron]

It's better to move such constants inside module where they're used.

[tyranron]

According to the spec we should convert into UTC here first.

[tyranron]

I think we can throw this squat out, because according to the spec we should convert into UTC, as we do for time crate. So allowing to preserve the input timezone in some cases is a helpful hatch in some cases, not the strict requirement.