Add a timezone-aware datetime GraphQL scalar type: DateTimeTz
obi1kenobi opened this issue · 2 comments
Since #827 merged, we don't have a way to represent timezone-aware datetimes. For this, I propose adding a new scalar type: scalar DateTimeTz
, Python name GraphQLDateTimeTz
.
A few guidelines I'd like to propose:
- Outputting a field of type
DateTimeTz
is guaranteed to produce a timezone-aware result. - Runtime arguments of type
DateTimeTz
are required to contain timezone information. - Its serialization as a string must always contain either an explicit
+HH:mm
suffix or the simple suffixZ
which is equivalent to+00:00
. Other suffixes, such as+HH
,+H
,America/New_York
etc. are explicitly not permitted and unsupported. - When auto-generating schemas, if a datetime type is explicitly known to carry timezone information (for example,
TIMESTAMPTZ
in many SQL flavors), it must be represented asDateTimeTz
in the auto-generated schema. - When auto-generating schemas, if it is uncertain whether a datetime type carries timezone information or not, it must be represented as
DateTime
(i.e. timezone-naive) and a warning must be emitted about the uncertainty. This warning must provide sufficient information to the user so that they are able to manually resolve the issue by explicitly configuring the field in question to appear as timezone-aware or naive.
This all sounds good to me. I'd like to mention a couple of points in support of this:
3. I think that the guideline you described here sticks completely with ISO standard and that makes sense to me. Sticking to the ISO standard makes the documentation and code simpler.
5. We already have some functionality to support this. We could tell the user to use class_to_field_type_overrides
in get_sqlalchemy_schema_info
and get_graphql_schema_from_orientdb_schema_data
to override the type in the GraphQL schema.
- I think that the guideline you described here sticks completely with ISO standard and that makes sense to me. Sticking to the ISO standard makes the documentation and code simpler.
Yes, exactly. And specifically, this is narrowing the ISO 8601 standard, which is huge — we don't have the resources to implement or support the whole thing.
- We already have some functionality to support this. We could tell the user to use
class_to_field_type_overrides
inget_sqlalchemy_schema_info
andget_graphql_schema_from_orientdb_schema_data
to override the type in the GraphQL schema.
Yes — I just wanted to make sure we don't frame the guidelines I proposed in terms of existing implementations or existing backend implementations. I'm fine with using existing code to achieve these goals.