6.0.0: Timestamp error despite legacy switch

[VILLAN3LL3]

In one of my integration tests, the following exception is thrown even though I have the legacy switch set to true in my dbcontext:

Cannot write DateTime with Kind=UTC to PostgreSQL type 'timestamp without time zone', consider using 'timestamp with time zone'. Note that it's not possible to mix DateTimes with different Kinds in an array/range. See the Npgsql.EnableLegacyTimestampBehavior AppContext switch to enable legacy behavior.

Here's the branch with the legacy switch set to true.

The failing test is this one: Should_Get_Appointments

Used package version:
<PackageReference Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="6.0.0" />

The test mentioned above queries the entity Appointment with the following predicate:

a =>
                    a.EndTime <= rangeEndTime && a.EndTime >= rangeStartTime
                    || a.EndTime > rangeEndTime && a.StartTime <= rangeEndTime,

The exception occurs if rangeStartTime or rangeEndTime are DateTime objects using the .Date property of DateTime, e.g.

myDate.Date

If I use

new DateTime(myDate.Year, myDate.Month, myDate.Day, DateTimeKind.Local)

it works.

[roji]

I cloned your repo, modified PostgreSQLConnection in appsettings.Test.json to point to a local database and ran the Should_Get_Appointments test, and it passed.

Can you please double-check the failure? If you're still seeing an issue, can you please isolate it in a more minimal runnable sample? Sending the entire project with all the infrastructure doesn't help to diagnose what's going on etc.

[VILLAN3LL3]

@roji Thanks for cloning my repo.
Yes, that's why I updated the issue description yesterday evening: I found out that the problem is using the .Date property of a DateTime object for a date query. I fixed it in this commit. The previous version will throw the exception, the new one will not. I'm not sure if this is a bug or the desired behavior. Can you evaluate this? (Please tell me if with this information you still need an isolated sample, then I will try to provide one)

[roji]

@VILLAN3LL3 in your repo, I reverted the commit the mentioned above (8710b9750561a46ba0ccc8866338f5258cad3938), and the Should_Get_Appointments still passes. I really need clear, simple instructions on how to see an actual failure here.

[VILLAN3LL3]

@roji With git checkout d934ec5d028e5507ec46bcdf04495b252e4ddeb0 I can reproduce the failure.
Anyway - I tried to provide a simple project to demonstrate the issue, but I wasn't able to reproduce it in this way.
So let's close this issue. I will re-open it if I can provide a simplified project.