Add support for parsing DateTime values

[ArjunNarendra]

Why make this change?

This PR is to address #3094, which is a bug that happens because the default type conversion for C# to Npgsql is to convert a string to a TEXT field, but this doesn't work when trying to compare a DATE type for PostgreSql databases.

What is this change?

I have updated ExecutionHelper.cs in ExtractValueFromIValueNode to explicitly handle SupportedHotChocolateTypes.DATETIME_TYPE and SupportedHotChocolateTypes.DATETIMEOFFSET_TYPE.

How was this tested?

• Unit Tests
• Integration Tests

Sample Request(s)

With query:

query {
  assignments(filter: { assignment_due_date: { gte: "2026-03-23T00:00:00.000Z" } }) {
    items {
      assignment_id
      assignment_name
      assignment_due_date
    }
  }
}

Before:

SELECT * FROM public."Assignments"
WHERE "Assignments"."assignment_due_date" >= '2026-03-23T00:00:00.000Z'::text;

After:

SELECT * FROM public."Assignments"
WHERE "Assignments"."assignment_due_date" >= '2026-03-23T00:00:00.000Z';

[Copilot]

Pull request overview

This PR addresses #3094 by ensuring GraphQL DateTime (and DateTimeOffset) argument values are parsed into typed CLR values before being passed to database providers, avoiding PostgreSQL treating them as text parameters in comparisons.

Changes:

• Added explicit handling for SupportedHotChocolateTypes.DATETIME_TYPE and SupportedHotChocolateTypes.DATETIMEOFFSET_TYPE in ExecutionHelper.ExtractValueFromIValueNode.
• Introduced local parsing helpers to convert string inputs into DateTime/DateTimeOffset-typed values using invariant culture + roundtrip parsing.

[ArjunNarendra]

This does not make too much sense to me...if we are dealing with SupportedHotChocolateTypes.DATETIME_TYPE shouldn't we return a DateTime (not a DateTimeOffset)?

[ArjunNarendra]

Ok, this makes sense.

[ArjunNarendra]

Ok, this makes sense although I am having some difficulty thinking of a concrete example when this would come into play.

[ArjunNarendra]

Ok, I can add a regression test.

[unattendedfaxmachine]

@ArjunNarendra I haven't managed to run the integration test slices against local backends successfully yet. Without that information, from my review we need to make sure these changes don't cause regressions in backends other than PGSQL. My main concern is that the normalization is currently implemented in shared GraphQL datetime extraction rather than a PostgreSQL-specific path, so it changes behavior for every backend that consumes the datetime scalar, including DateTimeOffset cases. I also do not see regression coverage proving SQL Server, MySQL, and Cosmos query generation still behaves correctly after this change, especially for offset-bearing filters. We need to make sure it doesn't break any other functionality. If you've already tested for regression, please disregard this comment. Otherwise, I've forked this repo and branch and started playing with local regression testing with docker here