7.0 Filter Expression Serializer Causes DataGrid LoadData Filtering Issues

Radzen.Blazor Components
1

We noticed some issues with DataGrid filtering on columns for DateTime values, and the 7.0 change to in-house expression parsing seems to be the source of the problem. This problem doesn't appear when using the newer .Where(grid.ColumnsCollection) method, it is only the .Where(args.Filter) version that has this problem. This issue can be reproduced easily in the DataGrid LoadData Demo by switching away from the newer overload and filtering on a DateTime column (the equals operator makes it most obvious):

@using System.Linq.Dynamic.Core
...
...
if (!string.IsNullOrEmpty(args.Filter))
{
    // Query cannot be transalated to SQL and filtering will be performed in-memory.
    if (selectedTitles?.Any() == true)
    {
        query = query.ToList().AsQueryable();
    }
    // Filter via the Where method
    query = query.Where(args.Filter);
}

Pre-7.0 args.Filter strings looked like this when selecting a DateTime with the time disabled / set to midnight:
it => it.ExpirationDate == DateTime(\"2029-06-30\")
Which produced a DateTime object correctly matching the inputted value for the current time zone.

After the 7.0 update, the args.Filter strings look like this instead when selecting the exact same value:
x => (x.ExpirationDate == DateTime.Parse(\"2029-06-30T00:00:00.000Z\", CultureInfo.InvariantCulture))
Which produces a DateTime object representing midnight UTC, rather than midnight in the current time zone.

So, When used in a LoadData like .Where(args.Filter), the value outputted to SQL is automatically put into the current time zone which produces a value 5 hours in the past of the actual selected value.
Based on Debugging, grid!.ColumnsCollection.ToFilterString() produces an identical filter string to args.Filter, so I would imagine the issue lies in the DynamicExtensions class moreso than the filter string generation.

Thanks for the help!

2

Thanks for the report! Please use this method instead until we investigate the problem.

3

Just checked the code pre v7 and it looks similar compared to latest:

4

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.

5

Sorry for taking so long to respond, I was on vacation over Memorial Day weekend here in the US. The fix you put out did restore the old functionality. Thank you so much for the help!