Skip to content

Add support for parsing DateTime values#3250

Open
ArjunNarendra wants to merge 1 commit intoAzure:mainfrom
ArjunNarendra:user/an/postgres-db-type
Open

Add support for parsing DateTime values#3250
ArjunNarendra wants to merge 1 commit intoAzure:mainfrom
ArjunNarendra:user/an/postgres-db-type

Conversation

@ArjunNarendra
Copy link

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?

  • Integration Tests
  • Unit 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';

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +398 to 401
SupportedHotChocolateTypes.DATETIME_TYPE => ParseDateTimeValue(value.Value),
SupportedHotChocolateTypes.DATETIMEOFFSET_TYPE => ParseDateTimeOffsetValue(value.Value),
SupportedHotChocolateTypes.UUID_TYPE => Guid.TryParse(value.Value!.ToString(), out Guid guidValue) ? guidValue : value.Value,
_ => value.Value
Comment on lines +425 to +432
if (DateTimeOffset.TryParse(s, CultureInfo.InvariantCulture, DateTimeStyles.RoundtripKind, out DateTimeOffset parsedDto))
{
return parsedDto.UtcDateTime;
}

if (DateTime.TryParse(s, CultureInfo.InvariantCulture, DateTimeStyles.RoundtripKind, out DateTime parsedDt))
{
return parsedDt;

if (raw is DateTime dt)
{
return new DateTimeOffset(dt);
SupportedHotChocolateTypes.FLOAT_TYPE => value is IntValueNode intValueNode ? intValueNode.ToDouble() : ((FloatValueNode)value).ToDouble(),
SupportedHotChocolateTypes.DECIMAL_TYPE => value is IntValueNode intValueNode ? intValueNode.ToDecimal() : ((FloatValueNode)value).ToDecimal(),
SupportedHotChocolateTypes.DATETIME_TYPE => ParseDateTimeValue(value.Value),
SupportedHotChocolateTypes.DATETIMEOFFSET_TYPE => ParseDateTimeOffsetValue(value.Value),
@unattendedfaxmachine
Copy link

unattendedfaxmachine commented Mar 13, 2026

@ArjunNarendra looks like copilot is complaining because DateTimeOffset isn't implemented here. We need to discuss and figure out how to handle the situation of TZ-aware/localized timestamps and the interaction between PG/DAB/GQL. Unlike SQL, Postgres inherently does not support the direct storage of localized timestamps and converts them to UTC. It's up to the user to store additional TZ data separately in the table and perform post computation.

These links may be a good place to start:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants