Provide a way to configure default timezone of DateTimes about graphene HOT 3 CLOSED

I agree with the comment on #590 that it is not Graphene's responsibility to define a default timezone for datetime values.

While I understand the potential issues that can arise from handling timezone-unaware datetimes, it is ultimately the responsibility of the developer to ensure that timezone aware datetimes are properly resolved for any DateTime types. Additionally, if the datetime value is not timezone aware, we cannot assume that it is in UTC.

Defining a default server timezone could potentially misrepresent the actual timezone for the underlying value, and as stated in issue #590, UTC should not be the default timezone. It is best to leave the responsibility of handling timezone-aware datetimes to the developer and not the framework.

The DateTime Scalar uses datetime.isoformat internally to convert datetime objects into ISO8601-compliant strings. This function includes an UTC-Offset if datetime.tzinfo is specified on the datetime object. Is there any reason why you can't set tzinfo yourself? You could easily extend the existing DateTime scalar, too.

Other than that, I agree with the points stated in #590. DateTime time zone settings should be an issue solved in userland.

from graphene.

Is there any reason why you can't set tzinfo yourself?

If it's coming from a database that doesn't store timezone info and assumes UTC.

You could easily extend the existing DateTime scalar, too.

Yes this is a work-around that needs to be handled on a case by case basis when it's discovered.
When using tools like graphene-sqlalchemy, the queries are auto-generated via this code, relying on graphene.DateTime.

Defining a default server timezone could potentially misrepresent the actual timezone for the underlying value, and as stated in issue #590, UTC should not be the default timezone.

That's true. However, the following assumptions are required for the existing timezone-unaware DateTime object not to be misrepresented:

• the client sends the datetime without tzinfo to the server and expects the server to send back that datetime as-is
• the client doesn't expect clients in other timezones to interact with it

If either of these assumptions turn out not to be true, then either the data the client saves won't be the same as what they get back, or the meaning of the datetime will be different for clients across different timezones (they'll both see e.g. 9pm in their respective timezones).

from graphene.

I've been digging further into this. I think this is a broader issue with some database implementations, in particular MySQL <-> SQLAlchemy, which in turn leads to problems resolving graphene.DateTime through graphene-sqlalchemy.

While still I think the current use case is a problem, I agree that graphene is not necessarily the place to resolve the issue, and this problem is more relevant at the sqlalchemy/graphene-sqlalchemy level.

from graphene.