Handling different time zones in Power BI is a common and important requirement, especially when building global reports where users or data sources operate in multiple regions. I’ve dealt with this in several projects — for instance, when sales transactions were recorded in UTC time, but regional teams wanted to view the data in their local business hours.
Here’s how I typically approach it:
First, I start by understanding the source system’s time zone. Many systems like SQL Server, Azure, or cloud APIs store timestamps in UTC, while others may store them in the server’s local time. Knowing this helps decide how and where to perform the conversion — in the data source, Power Query, or DAX.
If the data is in UTC, I often use Power Query (M language) to adjust time zones during data transformation. For example, to convert UTC to Indian Standard Time (IST, which is UTC +5:30), I add a custom column using:
DateTimeZone.SwitchZone([TransactionDate], 5.5)
This approach ensures the time is converted once during refresh, so visuals show the correct local time without recalculation.
In cases where different regions need different time zones, I take a dynamic approach. I maintain a small reference table — say, a “Region Time Zone Mapping” table — that defines offsets for each region (e.g., US -5, UK 0, India +5.5). Then, I create a calculated column or measure that adjusts timestamps based on the user’s region selection using DAX. This gives users flexibility to view the same data in their local context.
For example:
LocalTime =
VAR RegionOffset = LOOKUPVALUE(TimeZoneTable[Offset], TimeZoneTable[Region], SelectedRegion)
RETURN
Transaction[UTCDateTime] + (RegionOffset / 24)
Another effective technique, especially for global dashboards, is to display both UTC and local time fields — UTC for consistency in analysis and local time for operational visibility.
A challenge I’ve faced is daylight saving time (DST) adjustments. Fixed offsets don’t always work because DST changes vary across countries. In such cases, I prefer handling the conversion at the data source (for example, using SQL Server’s AT TIME ZONE function), since it automatically accounts for DST changes and avoids complex DAX logic.
For Power BI Service, one thing to note is that scheduled refreshes run in UTC, so I often adjust date filters (like “Today” or “Yesterday”) accordingly to ensure correct data range after refresh.
In short, managing different time zones in Power BI involves:
- Knowing your source system’s time zone,
- Converting consistently (in Power Query, DAX, or the source),
- Using dynamic region-based offsets if needed, and
- Handling DST carefully for accurate reporting.
This ensures reports remain accurate, user-friendly, and relevant for audiences across multiple time zones.