[andybak]

I hate to be "that guy" but I think everyone is looking at this wrong.

It's not a programming issue, a type casting issue or a CS issue.

It's a UI issue. That the point you got the date and the datetime values, there was a human being (either a user, an admin or a programmer) sitting in front of the screen and they were asked a question in some way.

The precise way that question was presented affected their intent. It's their intent you are asking about here. So you need to think about what they were asked and how they were asked it. If that was consistent then you can make a reasonable call here. If it's inconsistent at different times and places then the meaning of that date is different and you can't solve this in any reasonable way.

[pg_1234]

Often it is first and foremost a type casting issue.

Whether you are comparing a date to a datetime or saving a date as a datetime, almost every language turns '2022-01-02' into something like '2022-01-02T00:00:00+0000' i.e. the first second of the day.

In practice it is usually safer to convert to '2022-01-02T12:00:00+0000', centering the time in the day and minimizing the chance that timezone related or other errors will move you into a whole new day.

The time component is always a lie, but noon is the safest lie.

[andybak]

That seems to be completely counter to the point I was trying to make. It's nothing to do with type casting - you need to consider the intent of the human being who created that data. What did they mean?