pkp/pkp-lib#9132 fix SQL datetime and date comparison for editorial s…

[bozana]

s. #9132

[bozana]

@asmecher or @jonasraoni, could one of you review this change?
I think DATE() can be used for both, MySQL and PostgreSQL, right?

[jonasraoni]

@bozana the DATE isn't a function in PostgreSQL, but a construction, you can use it this way: SELECT DATE '2023-01-01 10:22:22' :D
But it works, so it's fine, another option that works for both would be CAST('2023-01-01 10:22:22' AS DATE)

[jonasraoni]

And about the change... I've already had issues with it, see #7709 and #6011, AFAICR, it's not possible to reach a perfect solution (e.g. a solution might fit the QuickSubmit, but not the Native XML plugin and other import tools out there).

Personally, I'd drop this heuristic. It doesn't work very well and will have to be maintained forever.

Basically, to drop the concept of imported records for now, and recover it once the #8389 gets implemented. Users that imported content, should understand that it might affect statistics, but that's just my opinion =]

[bozana]

Thanks @jonasraoni. To be on the safe side, I will then use CAST(X AS DATE)...

[bozana]

@jonasraoni, now I used CAST(X AS DATE). OK so?
I will not remove that heuristic now -- it is already there for some time, and the user might got used to it in a way, and it did solved a problem... So, lets hope the right solution will come soon... :-)

[jonasraoni]

I think it's better/more standard.

About the heuristic, we would need the approval from @asmecher, I just wanted to raise the flag regarding the existing issues and future maintenance burden.