Timestamptz should use toUtc().toIso8601String()

[orestesgaolin]

There's a type timestamptz in PostgreSQL database that includes a tz information (timezone offset). When using it with default DateTime as type in build runner configuration, it may lead to errors where timezone gets lost.

build.yaml:

targets:
  $default:
    builders:
      graphql_codegen:
        options:
          scalars:
            timestamptz:
              type: DateTime

In Dart if DateTime is in the local timezone of the device the call to toIso8601String() results with a string without Z in the local timezone of the device. When sent via graphql mutation to a PostgreSQL database it will be interpreted as if this was in the UTC timezone.

  // in UTC+1 timezone
  final date = DateTime(2024,01,01,01);

  print(date.toUtc()); // 2024-01-01 00:00:00.000Z
  print(date.toIso8601String()); // 2024-01-01T01:00:00.000
  print(date.toUtc().toIso8601String()); // 2024-01-01T00:00:00.000Z

I suggest that graphql_codegen should include default timestamptz converter, e.g. something like:

DateTime timestamptzFromJson(String json) {
  return DateTime.parse(json);
}

String dateToJson(DateTime object) {
  return object.toUtc().toIso8601String();
}

targets:
  $default:
    builders:
      graphql_codegen:
        options:
          scalars:
            ISODateTime:
              type: DateTime
            timestamp:
              type: DateTime
            timestamptz:
              type: DateTime
              fromJsonFunctionName: timestamptzFromJson
              toJsonFunctionName: dateToJson
              import: package:my_package/my_package.dart

[github-actions]

👋 @orestesgaolin
Thank you for raising an issue. I will investigate the issue and get back to you as soon as possible.
Please make sure you have provided enough context.

This library is created and maintained by me, @budde377. Please consider supporting my work and ensure our survival by donating here.

[budde377]

Thank you for creating this issue. Date-times are complex and very hard to generalise. I would advice anyone to review the DateTime provided and determine if it meets the requirements of their setup and implement appropriate parsers. Changing the underlying implementation might cause a lot of issues for existing users, and as I said are probably not going to work for everyone, so I am reluctant to change it.

[orestesgaolin]

Thanks for clarification, I understand your concern. By having the issue here I hope some other folks stumble upon it and make their converters aware of timezone.

Do you mind if I update the readme with one more example of converter?

[budde377]

That would be very useful - please feel free!