DateTime Filter Converts Local Time to UTC Causing Incorrect SQL Queries

[Steinmetz]

Dear Radzen Support,

we are experiencing an issue with how DateTime values are handled in server-side filters when using Radzen with a Blazor Server application.

We are using a filter like this in our service call:

Filter = "i => i.BuchungDatum == @0 && i.BuchungArt == @1 && i.BuchungBetrag == @2 && i.BuchungId != @3 && i.BuchungBilanz == @4",
FilterParameters = new object[] { i.BuchungDatum, i.BuchungArt, -1 * i.BuchungBetrag, i.BuchungId, bilanzCode }

At runtime, i.BuchungDatum holds a local DateTime value, e.g., 2025-05-01 00:00:01. However, the generated SQL query uses 2025-05-01 02:00:01 instead, which corresponds to the UTC equivalent of the original timestamp (we are in a UTC+2 timezone at this date).

This automatic conversion leads to incorrect results, as the filter fails to match existing records in the database, which store the value exactly as 2025-05-01 00:00:01.

We have tried explicitly setting the DateTimeKind to Unspecified or Local, and also converting to UTC manually, but the behavior persists. The only workaround that consistently works is manually subtracting 2 hours from the timestamp before passing it to the filter – which is obviously not a clean or reliable solution.

We assume this issue is caused by the way Radzen handles parameter serialization and/or EF Core interprets DateTime values internally.

Could you please advise:

Is there a way to prevent Radzen or EF Core from converting local DateTime values to UTC in generated queries?

Would using DateTimeOffset instead of DateTime resolve this issue in your framework?

Is there any recommended approach to avoid this unintended time shift?

We would greatly appreciate any guidance or clarification.

Best regards,

[enchev]

Fix for this will be released tomorrow:

7.0 Filter Expression Serializer Causes DataGrid LoadData Filtering Issues

I was able to replicate the difference. Here is the missing part: We will do our best to add fix in our next update next week.

[Steinmetz]

Thanks, enchev. Looking forward to it.

[enchev]

Already released! You can update your app to Radzen.Blazor 7.0.7 (or simply * to get the latest NuGet package).

[Steinmetz]

Well, it didn't fix my problem though. I updated my Radzen package via NuGet:

but I still need to do this:

var datumUnspec = i.BuchungDatum.AddHours(-2);

var gefundeneBuchungen = await webassetsService.GetBuchungen(new Radzen.Query
{
    Filter = "i => i.BuchungDatum == @0 && i.BuchungArt == @1 && i.BuchungBetrag == @2 && i.BuchungId != @3  && i.BuchungBilanz == @4",
    FilterParameters = new object[] { datumUnspec, i.BuchungArt, -1 * (i.BuchungBetrag), i.BuchungId, bilanzCode }
});

to get the query:

SELECT "b"."buchung_id", "b"."buchung_afa_kum", "b"."buchung_art", "b"."buchung_asset", "b"."buchung_betrag", "b"."buchung_betrag_brutto", "b"."buchung_bilanz", "b"."buchung_datum", "b"."buchung_erlös", "b"."buchung_kos_aktuell", "b"."buchung_option", "b"."buchung_rbw", "b"."buchung_text", "v"."vst_option_id", "v"."vst_option_nr"
FROM "buchungen" AS "b"
LEFT JOIN "vst_optionen" AS "v" ON "b"."buchung_option" = "v"."vst_option_id"
WHERE "b"."buchung_datum" = '2025-05-01 00:00:01' AND "b"."buchung_art" = 10 AND "b"."buchung_betrag" = -5.0 AND "b"."buchung_id" <> 28847 AND "b"."buchung_bilanz" = 1

otherwise the query looks like this:

SELECT "b"."buchung_id", "b"."buchung_afa_kum", "b"."buchung_art", "b"."buchung_asset", "b"."buchung_betrag", "b"."buchung_betrag_brutto", "b"."buchung_bilanz", "b"."buchung_datum", "b"."buchung_erlös", "b"."buchung_kos_aktuell", "b"."buchung_option", "b"."buchung_rbw", "b"."buchung_text", "v"."vst_option_id", "v"."vst_option_nr"
FROM "buchungen" AS "b"
LEFT JOIN "vst_optionen" AS "v" ON "b"."buchung_option" = "v"."vst_option_id"
WHERE "b"."buchung_datum" = '2025-05-01 02:00:01' AND "b"."buchung_art" = 10 AND "b"."buchung_betrag" = -5.0 AND "b"."buchung_id" <> 28847 AND "b"."buchung_bilanz" = 1

[enchev]

Hmm it seems that I misunderstood the problem? Is this a WebAssembly app? Dates are always sent as UTC.

[Steinmetz]

Just to clarify: our application is a Blazor Server app, not WebAssembly. We are running everything on the server using AddInteractiveServerComponents() and have only a single project in our solution. So there is no client-side execution that would convert DateTime values to UTC via JavaScript or JSON serialization.

Despite this, we’re still seeing that DateTime filter parameters are internally treated as UTC when the SQL query is generated – even though we are passing in a DateTime value like 2025-05-01 00:00:01 (with DateTimeKind.Local or Unspecified). The generated SQL ends up comparing against '2025-05-01 02:00:01', which is the UTC equivalent, and thus does not match the actual data stored in the database.

The only workaround that currently works is manually subtracting two hours before passing the value into the filter, which is obviously not ideal or reliable.

Could you please double-check if Radzen or EF Core is applying an internal UTC conversion when building the query? And is there a way to explicitly control or disable this behavior?

Thanks again for your help!

[enchev]

Here is what I've tried in a new scaffolded Blazor server app using our sample database Orders:

Here are also all places in our code where Utc is used:

[Steinmetz]

@enchev

Here are also all places in our code where Utc is used:

Thanks for testing this in your sample project.

However, I think the issue is not whether UTC conversion happens (we both now see that it does), but how to prevent it when local time is intended.

In our application, the DateTime values used for filtering are explicitly set as local time or DateTimeKind.Unspecified. The database stores these timestamps exactly as entered (e.g., 2025-05-01 00:00:01) without any timezone or offset. When Radzen or EF Core converts the parameter to UTC (e.g., 2025-05-01 02:00:01), the filter no longer matches the actual value in the database.

Your example confirms the conversion happens, but how can we stop that behavior if we want a local time comparison?

Is there a way in Radzen to prevent this automatic conversion to UTC, or should we migrate our filters to use DateTimeOffset instead?

Looking forward to your recommendation.

[enchev]

Not sure how my example confirms that there is UTC conversion? These are not UTC dates:

[Steinmetz]

Hi enchev and thanks for your reply.

I think we might be talking past each other slightly, so I’d like to clarify the core of the issue I’m observing. In your screenshot, the SQL query shows this filter clause:

[o].[OrderDate] >= '2002-04-28T03:00:00.0000000+03:00'

However, in your C# code you use

DateTime.Parse("04/28/2002")

By default, this should result in a DateTime with kind Unspecified, and logically represent midnight of 2002-04-28. Still, the SQL query shows a time of 03:00:00, which suggests that somewhere in the processing pipeline (possibly during serialization or EF Core translation), a conversion to UTC is happening – assuming you are in a UTC+3 time zone (e.g. Romania).

This is exactly the behavior I’ve been struggling with. In my case, I pass a local DateTime like 2025-05-01 00:00:01, but in the generated SQL it becomes 2025-05-01 02:00:01, which doesn’t match the stored value in the database (which is exactly 2025-05-01 00:00:01).

I’m not questioning that your code works technically – I’m trying to understand why this time shift is happening, and whether Radzen or EF Core is implicitly converting these DateTime values to UTC (based on local system time zone), even when the DateTimeKind is Unspecified.

Is there a recommended way to make sure time values are sent exactly as entered, without time zone adjustment?

Thanks again for your help – I just want to ensure consistent behavior when filtering by exact timestamps.

[enchev]

I’ll repeat once again what I already said. - these are not UTC dates:

[Steinmetz]

@Steinmetz

Is there a recommended way to make sure time values are sent exactly as entered, without time zone adjustment?

Well then I once again will ask, if there is a recommended way to make sure time values are sent exactly as entered, without time zone adjustment?

[enchev]

If you want dates without time zones you should use UTC dates.

[Steinmetz]

Thanks for the reply. I understand your recommendation to use UTC for consistency — and that’s exactly what I’m doing now using:

var datumUnspecUTC = DateTime.SpecifyKind(i.BuchungDatum, DateTimeKind.Utc);

System.Diagnostics.Debug.WriteLine($"Timecode found: {datumUnspecUTC}");

var gefundeneBuchungen = await webassetsService.GetBuchungen(new Radzen.Query
{
    Filter = "i => i.BuchungDatum == @0 && i.BuchungArt == @1 && i.BuchungBetrag == @2 && i.BuchungId != @3  && i.BuchungBilanz == @4",
    FilterParameters = new object[] { datumUnspecUTC, i.BuchungArt, -1 * (i.BuchungBetrag), i.BuchungId, bilanzCode }
});

However, here’s the issue I’m still facing:

Even though I explicitly set the DateTimeKind to Utc, and the debug output confirms it, the actual SQL command sent to the database is:

Timecode found: 01.05.2025 00:00:01
Microsoft.EntityFrameworkCore.Database.Command: Information: Executed DbCommand (2ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
SELECT "b"."buchung_id", "b"."buchung_afa_kum", "b"."buchung_art", "b"."buchung_asset", "b"."buchung_betrag", "b"."buchung_betrag_brutto", "b"."buchung_bilanz", "b"."buchung_datum", "b"."buchung_erlös", "b"."buchung_kos_aktuell", "b"."buchung_option", "b"."buchung_rbw", "b"."buchung_text", "v"."vst_option_id", "v"."vst_option_nr"
FROM "buchungen" AS "b"
LEFT JOIN "vst_optionen" AS "v" ON "b"."buchung_option" = "v"."vst_option_id"
WHERE "b"."buchung_datum" = '2025-05-01 02:00:01' AND "b"."buchung_art" = 10 AND "b"."buchung_betrag" = -5.0 AND "b"."buchung_id" <> 28847 AND "b"."buchung_bilanz" = 1

So the database receives the date as 2 hours ahead of what I passed in, despite it being UTC.

This leads me to the central question:
Where is this +2 hour offset being added?
Even when using DateTimeKind.Utc, something in the stack — Radzen? EF Core? the database driver? — seems to be converting it to local time (UTC+2 in my case).

[enchev]

You can specify in your DbContext that you want specific DateTime property to be UTC:

[Steinmetz]

Thank you. Now it works.

[Steinmetz]

Let me rephrase that...

Thank you for the previous suggestion. Using the .HasConversion() with ToUniversalTime() does fix the reading issue, but unfortunately shifts written values 2 hours backward when saving, which is not acceptable in our case. Without the conversion, the values are stored correctly, but reading them adds 2 hours. My goal is to store and read the date exactly as my code intends to - without any timezone-based shift in either direction. Is there a recommended way in Radzen/EF Core to achieve this behavior without applying bidirectional conversion?

[enchev]

I'm afraid that the UTC is the only option I know. Feel free to search StackOverflow or other source for better.