Filtering date measures or dimensions by "before or on date" doesn't work

[willianba]

Describe the bug
When filtering a timestamp dimension with the "before or on date" operator, it doesn't bring the correct values due to a wrong logic in the generated SQL.

This is running on postgres.

To Reproduce
Steps to reproduce the behavior (at least the way I ran it):

1. Go to Playground
2. Filter by any timestamp dimension or metric (like a created_at)
3. Select the "before or on date" operator
4. Set the current day value (considering you have data on this day). E.g. 2025-06-05.

Expected behavior
Data on this exact day should be returned.

Screenshots
First, proof that there is data on the requested date.

Now, using before or on date. All the values on the request date are not present in the response.

Minimally reproducible Cube Schema

cube(`events`, {
	sql_table: `public.event`,
	data_source: `default`,

	dimensions: {
		created_at: {
			sql: `created_at`,
			type: `time`,
		},
});

Version:
v1.3.19

Additional context
The example I gave uses a dimension but this bug also happens for measures.

I quickly inspected the generated query and it has the wrong value for the given operator.

For after or on date it should be >= '2025-06-05T00:00:00.000Z'::timestamptz, which is working fine. But for before or on date it should set the hour to the max and reverse the operator: <= '2025-06-05T23:59:59.999Z'::timestamptz.

This is what is being generated:

select
	"audience_filter".contact_id "audience_filter__contact_id",
	("audience_filter".created_at::timestamptz at TIME zone 'UTC') "audience_filter__created_at"
from
	public.event as "audience_filter"
where
	("audience_filter".created_at <= '2025-06-05T00:00:00.000Z'::timestamptz) -- wrong date time here
group by
	1,
	2
order by
	2 desc
limit 10000

[willianba]

I got lazy to create another issue, but the "after date" is also wrong.

It generates > '2025-06-03T00:00:00.000Z'::timestamptz. I believe it should be > '2025-06-03T23:59:59.999Z'::timestamptz to get everything after the end of the day. Because nowadays it gets data after the exact beginning of the day: