Forum Discussion
PowerBi vs. Amazon Redshift Different Minimum Report_Date from the same table After UTC Midnight
Hi UKapadia ,
Thank you for the update. Since adjusting the timezone logic did not resolve the issue and today's records are still missing after the UTC date transition, it would be helpful to review the exact query or filtering logic that is being used to return the current day plus the next three days.
Could you also confirm whether the dataset is using Import mode or DirectQuery. Microsoft Learn documents that current date/time functions can be evaluated differently across environments, but additional query details would be needed to determine why the current day's records are being excluded in Power BI while they continue to appear in DBeaver.
References:
https://learn.microsoft.com/en-us/powerquery-m/datetime-localnow
https://learn.microsoft.com/en-us/powerquery-m/m-local-fixed-utc-variants
Hey, my thinking that it's a timezone thing in Redshift, not Power Query.
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
Hi Shai,
Thank you for your support.
As you asked, I wanted to share an observation regarding the min/max query results I ran simultaneously in DBeaver and Power BI. where I noticed a discrepancy: Power BI indicates there is no data for 05/29, while DBeaver shows available data for the same date.
To address this, I plan to update the report_date according to the logic you provided tonight at 19:00 CST / 00:00 UTC. I’ll keep you updated on how it goes. one funny thing, I have many different dashboard and they are not impacted but I have few other team members who are facing the same issue with their new dashboard or publishing the new enhancement.
Thanks again for your assistance!