How to Change Time Zone in Power BI Service

Ensuring your Power BI remembers the correct time zone can be surprisingly tricky. By default, most reports on the Power BI Service operate using UTC (Coordinated Universal Time), which can skew your charts and timelines if your data or users are located in different areas of the world. This article walks you through the methods to customize time data so you can make your analyses relevant for all your audience.

Graphed

Build AI Agents for Marketing

Build virtual employees that run your go to market. Connect your data sources, deploy autonomous agents, and grow your company.

Build Your First Agent

Understanding Power BI and Its Dual Personalities

There is a great deal of confusion about how Power BI functions, particularly for users without a Data Engineering background. The confusion often stems from the fact that Power BI has two distinct "personalities" - or more accurately, two different systems: Desktop and the Cloud.

Power BI Desktop's Regional Settings

When you are authoring reports in Power BI Desktop, the local settings on your computer are automatically taken into account. This is very convenient for report authors since it displays dates and times in a localized manner - i.e., in their own specific time zone. You can even change this. You can use the 'Regional Settings' to customize how data is displayed. This is done on a file-by-file basis, and the report author has total control over each report. Just go to the Data - Load section, and you will see a setting that says "Locale for import/region." From here, you can set your preferences.

While handy, this behavior can be misleading. As we will see in the next section, these dates can be displayed in an entirely different time zone depending on the country the file is being viewed in. Understanding why this happens is key - so next, we will look at the Power BI Service...

The Power BI Service's Universal Approach

However, there's a significant "gotcha." Once you share your report to the Power BI Service (the server-based environment from Microsoft), the system no longer uses local time zone preferences. Instead, it uses the industry-standard "UTC" time format. This is done for simplicity, as it helps streamline calculations involving periods and dates. Relying on a known, unique reference date/time is easier for developers and is a universally agreed approach.

This explains why two different dates can appear in a report. It is often a cause for alarm, and for good reason. One might easily assume that the data can become incorrect - which, of course, it isn’t. The great news is that Power Query, together with the aid of our favorite data language called DAX, are sufficiently powerful to handle this challenge. They were designed specifically with such problems in mind!

Adjusting Time Fields to UTC in Power BI

Adjusting your timestamps to UTC within Power Query is the best start. In the following sections, we will see how Power Query can be deployed to handle this task. We’ll also ensure you see instructions for a couple of general scenarios that can occur, both of which are very common. These examples will ensure you can best resolve each case in your own datasets, as they'll differ depending on how they’re provided to any Power BI report author. Understanding these processes can help avoid some challenges that can cause significant disruption for even the most seasoned report authors.

AI Agents for Marketing

Crash Course

Graphed

Free PDF · the crash course

AI Agents for Marketing Crash Course

Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.

Download the PDF

Scenario 1: Your data has a separate column for the time zone

Let’s say, for example, your data has been prepared by your product team and is nicely organized with the time zone in its own column. This makes things much easier for us, as we can use this to our advantage rather than using a more complex feature such as a fixed offset. For this type of data, we want to combine the two columns so that Power BI can create what is called a "datetimezone". If we don't, Power BI may get it wrong, which is what we are trying to avoid! Once these are combined, there is a great feature within Power Query that will enable us to convert it to UTC time. To do that, you will be creating your own column using the "Add Custom Column" feature within Power Query.

[timecolumn] & " " & [timezone_column]

With that completed, your new column (now containing both a time and a time zone) is set correctly. You can click that new column heading in the table and then choose the option you need. In this case, you will be clicking "Transform" and then selecting the option that says "UTC Time Zone." By clicking this, it converts your time. Done!

Scenario 2: Your data has a single time zone

This is a bit more challenging as there’s more for us to do. However, it's not something that can't be resolved, and it is indeed very common. For this, you’ll need to perform a few more steps. This time, we’ll create our custom column but will use some specific functionality from Power Query to execute it efficiently. So instead of combining two fields as in Scenario 1, we can create this using one function like this:

(Source as datetime) => let toUtcTime = DateTimeZone.ToUtc(DateTime.AddZone(Source, 2)) // Change to the value you need. In this case, '2' is for CET, for example. in toUtcTime

Let’s explore this a bit further as a lot is happening here! It takes a "datetime" value as its input (the field 'datetime' can often be called this in your records, just substitute the source for the correct name that you’re using!). This is important, as the function needs to be in this structure. The function returns the equivalent time in a different time zone by doing a simple offset function on its own. In this case, the number ‘2’ has been used, but it can be any offset you need for that date. There are many sites that can show what such time-zoned offsets should be using worldwide. The DateTime.AddZone is used to add in the time zone. A better solution can be deployed to make this more flexible: using a table to do the lookup rather than hard-coding a single variable!

If everything is already set up correctly, you can now update the 'new' custom column created for you and make it your new field as the input to a chart or a table in Power Query Desktop, safe in the knowledge that once it goes to the Power BI Service for publishing, the data is available in a unique and consistent standard of UTC. So at the end of the day, no more nasty surprises! Is there an even cleaner way? Yes! See the next section with the concept of a dynamic offset chart and how it can really assist!

Graphed

Build AI Agents for Marketing

Build virtual employees that run your go to market. Connect your data sources, deploy autonomous agents, and grow your company.

Build Your First Agent

Scenario 3: Using a table of Offset values for a more 'dynamic solution'

As highlighted above, there is an even better approach for scenarios which involve frequently changing time offsets repeatedly. For this, we will be setting up a time zone table. Inside this table, you will require a few fields that are quite standard: The Country or Regional zone name is a good start, and the offsets themselves are critical. It’s also good to include the standard abbreviation for the named convention, as these could be used in a label inside a graph or a map label when needed, making things clearer for an audience. As a guide, you can use a lookup table like this below:

• Universal Time Grid, Eastern Greenland Standard Time (EGST), 2
• Co-ordinated Universal Time, Central European Standard Time (CET /CEST - During DST), 1
• etc...

Your solution might look something like this:

`(Source as datetime, TimeZone as text) => let // A very simple demonstration of a set of values... timeZonesMap = #table({"TimeZone", "Abbreviation", "Offset"}, { {"Alaskan Standard Time", "AKST", -9.0}, {"Central European Summer Time", "CEST", 2.0}, {"Greenwich Standard Time", "GST", 4.0}, {"India Standard Time", "IST", 5.5}, }), ZoneRows = Table.SelectRows(timeZonesMap , each ([TimeZone] = TimeZone)), //If you do not get a match back then you can default to 0 (UTC!) Actual_offset = if Table.RowCount(ZoneRows) > 0 then ZoneRows{0}[Offset] else 0,

     Output = DateTimeZone.SwitchZone(DateTimeZone.From(Source), Actual_offset, 0)

 in    
     Output`

This function allows you to look up the key provided as input into the function, dynamically using the offset from the table (called timeZonesMap). It does this in a secure way by using the provided text values. It also has a final check that defaults to an offset of '0' if no matching time zone is found. Returning a value of 0 in this case means it will just keep your data in UTC time format, as an offset of '0' means no modification. This makes this function powerful!

Using DAX to Handle Time Zone Customizations

If it’s not performed through Power Query, do not fear, the equivalent can be done using flexible functions inside Power BI. It’s important to remember another key fact: using Power Query involves 'behind the scenes' analysis, and we need to refresh the query to see changes. One of DAX's main differentiators compared to Power Query is that DAX functions in real-time reporting, updating as the charts are being rendered.

This means using a calculation with DAX shows values on the fly without needing to 'refresh your data again'. This makes the process streamlined and means calculations can now take advantage of any other variables available on the report front, such as sliders and buttons from report controls. Let's look at a few examples. We'll start with a simple example, moving toward a more dynamic and elegant solution.

DAX Solution with a Single Offset

Very similar to the Power Query example, this DAX solution will take data from your dataset and add additional hours using a simple DAX formula. At the end, it’s returned as a new field as part of our primary data table, so it may be worth giving your table a descriptive name so it's not confused with the originating data sets. Our simple calculation this time will use the FORMAT function in DAX, but a word of caution: the FORMAT function is known in the Power BI community as a feature that can sometimes cause issues if not utilized correctly. It converts the date-time value to a string, meaning you won’t be able to use it with native date-driven insights in Power BI. Using it as a simple table or in a standalone visual like a card will not pose a problem - so it's something to bear in mind when using this approach.

Date in UTC := FORMAT('NameOfYourTable'[date_and_time] - (5 / 24), "General Date/Time")

Here we're subtracting a time value by taking a fraction of one. The solid figure '24' will always represent the 24 hours within a day. The '5' in the numerator, in this case, is the specific offset we wish to apply. If you closely observe this formula, you’ll notice that the format "General Date/Time" is being returned, hence why it should only be used for visual elements with no further downstream use for the data. Following this as a rule of thumb is often a pitfall for the unwary, as your dates now lack a number of the natural features that are offered by Power BI's suite of time intelligence capabilities!

AI Agents for Marketing

Crash Course

Graphed

Free PDF · the crash course

AI Agents for Marketing Crash Course

Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.

Download the PDF

Dynamic 'On-The-Fly' Time Zones

Now we have seen a solution that commits one of the best 'cardinal sins' from Power BI by using the FORMAT function for our data. It's time to demonstrate that the same outcomes can be achieved in a way that keeps its natural type functions without sacrificing any of the power. A much 'cleaner' function can show how this is addressed in a single line of code using a function that is more robust.

UTC date = DATEADD([local time column] , [-5],HOURS)

The function shown above is considerably better than its FORMAT predecessor for several reasons! First of all, it's incredibly obvious where we can perform a change to the value of the input offset (in this case 3). Even better, by using just three simple parameters to complete the function: 'Name of the column', 'Your Required Offset', and perhaps most importantly, the unit of the data being passed in. For our example, we have chosen HOURS. No calculations are required in terms of 5/32 as typically done in value terms, it is a question of having to piece together the calculation... one can easily see this offset now! Moreover, it preserves its source data structure as a time/date value, which means that the solution does not in any way prevent the use of all the great properties provided to you as a report author with Time Intelligent capabilities in DAX!

Final thoughts

Managing time zones in Power BI is a task that can catch even the most seasoned analysts off guard if you aren’t aware of the duality of Power BI. The best practice for analyzing your data is to use a standard time like UTC. From there, it doesn't matter where your data is observed because it will have a standard that can be altered using offset functions, guaranteeing a high level of confidence from the person analyzing it. The confusion often arises when Power BI Desktop displays local system times, while Power BI Service shows data in a UTC format. We hope this has clarified some of these seemingly contradictory messages.

By taking a straightforward approach, there’s no need to be overly concerned when something in a report doesn't match your expectations for your local time. This is simply another example of a mundane process that needs to be considered for most BI analysis. With Graphed, a lot of these considerations are handled directly out of the box! The more advanced tools require attention to data types, file formatting, and time zones. By using a more intelligent approach that includes AI, these concerns are automatically managed, allowing you to focus on analyzing your business operations. This is a powerful aspect of our platform, which we believe provides a significant advantage, streamlining your workflow upon connecting to your data sources. Now you can query something like 'How many hours were our sales in NY yesterday?' and receive instant results, eliminating manual processes. With Graphed , we connect to your sources to deliver real-time data so you can effortlessly do just that!