Inconsistent timezone handling

[megatrond]

Describe the bug
Just to preface - I'm not sure if this is a bug or a feature, it just left me a little confused and after talking with darrell.neo on Discord we agreed it could be filed to serve as documentation.

Our schema has a DateTime field and when we pass iso8601 strings with no timezone offset (zulu times) in, we get zulu times back from the graphql api. But - the field is stored in neo4j with an offset, and this offset seems to be dependent on which timezone nodejs is configured with.

On my local machine, running node without any timezone configuration stores the fields in neo4j with a +2 offset. Adding the following line to our graphql api code: process.env.TZ = 'Zulu'; will cause the times to be stored without an offset when querying with cypher.

This behaviour is completely hidden when looking at this from the graphql side, as we both pass zulu times in and reliably get zulu times back when doing graphql queries.

I think one of two things should happen:

1. Either, what gets passed in is also what is stored - so if we pass offsets over graphql, the offset information is also stored in neo4j
2. Or, what gets stored is also returned - so if neo4j has stored a time with a timezone offset, that offset is also returned over graphql

I'm happy to provide more information if needed!

[neo4j-team-graphql]

Many thanks for raising this bug report @megatrond. 🐛 We will now attempt to reproduce the bug based on the steps you have provided.

Please ensure that you've provided the necessary information for a minimal reproduction, including but not limited to:

• Type definitions
• Resolvers
• Query and/or Mutation (or multiple) needed to reproduce

If you have a support agreement with Neo4j, please link this GitHub issue to a new or existing Zendesk ticket.

Thanks again! 🙏

[neo4j-team-graphql]

Many thanks for raising this bug report @megatrond. 🐛 We will now attempt to reproduce the bug based on the steps you have provided.

Please ensure that you've provided the necessary information for a minimal reproduction, including but not limited to:

• Type definitions
• Resolvers
• Query and/or Mutation (or multiple) needed to reproduce

If you have a support agreement with Neo4j, please link this GitHub issue to a new or existing Zendesk ticket.

Thanks again! 🙏

[btroop]

i was runnig into some weird timezone stuff as well and hacked my way around it by using the supported LocalDateTime type. But agreed that there are some weird ways that dates are generated on a client, sent through graphql, stored in neo4j, then read through graphql that transform the data away from the original generated date w/ timezone.