PowerBi vs. Amazon Redshift Different Minimum Report_Date from the same table After UTC Midnight

In Redshift, CURRENT_DATE and GETDATE() return their value in the session timezone, which defaults to UTC.
Your DBeaver connection and the Power BI connector are running in different timezones, and that's the whole bug.

At 7 PM CST on 5/29 it's already 00:00 UTC on 5/30. DBeaver sits in Chicago time so CURRENT_DATE is still 5/29 and keeps those rows, MIN = 5/29. Power BI runs in UTC so CURRENT_DATE already flipped to 5/30, the filter silently drops the 5/29 rows, MIN = 5/30. Same table, same query, different answer.

Your local_today column actually might prove it, it's correct because you wrapped it in CONVERT_TIMEZONE, but the actual row filter still uses bare current_date which is UTC. That's the gap. And current_date - 1 failed because it shifted the whole window instead of fixing the boundary.

Fix: anchor the filter to a local date instead of bare current_date.

WHERE a.report_dt::date
  BETWEEN CAST(CONVERT_TIMEZONE('UTC','America/Chicago', GETDATE()) AS date)
      AND CAST(CONVERT_TIMEZONE('UTC','America/Chicago', GETDATE()) AS date) + 3

One check decides the left side: if report_dt is stored as UTC, convert it too (CONVERT_TIMEZONE on a.report_dt). If it's already local Chicago time, leave it as ::date. Confirm with:

SELECT a.report_dt, CONVERT_TIMEZONE('UTC','America/Chicago', a.report_dt) AS local_dtFROM your_view a ORDER BY a.report_dt LIMIT 5;

If the raw boundary row reads 2026-05-30 00:30 it's UTC (convert it), if it reads 2026-05-29 19:30 it's already local (don't).

And if you want to prove the diagnosis first, run this in both tools and compare:

SELECT CURRENT_DATE AS cd, GETDATE() AS gd, CURRENT_SETTING('timezone') AS tz;

I'm pretty sure different tz between them is your smoking gun.

I'm curious how it goes for you, let me know.

If this works for you, kindly mark it as the solution and give a thumbs up.

Best,
Shai Karmani

Let's connect in LinkedIn