Incorrect Date/Time in Power BI Service

[Jays_D]

Hi All,

I know this is a common question/problem re: date/time in service - but I can't seem to find anything to help me solve it for my situation and could really use some help/guidance.

I have the same issue, date/time present correctly in Desktop, and look fine when published to service until next refresh, it defaults back to UTC.

The concern I have is, this report has over 40 date&time columns, all of which have calculated columns and many visuals over many tabs that are associated. 

Is there any way I can do a blanket approach across all date columns to "hard code" -10 hours to each? - clutching at straws here. Also being quite new to Power BI, I may just not be aware of a simple solution available.

[vs_7]

Hi @Jays_D ,
try the below steps

The issue you're facing with date/time columns in Power BI Service defaulting back to UTC after a refresh can be frustrating, but there are some ways to address this, although they may require some effort.

1. **Check Date/Time Zone Settings in Power BI Desktop**:
- First, ensure that the date/time columns in your Power BI Desktop file are correctly set to the desired time zone. Power BI Desktop usually detects the time zone of your computer and sets the data accordingly. You can review and adjust the time zone settings for each column in the "Modeling" tab under "Data Type" for date/time columns.

2. **Use a Time Zone Offset Calculation**:
- If you want to apply a blanket approach to adjust all date/time columns by a fixed time zone offset, you can create calculated columns in Power BI Desktop that subtract the desired offset from each date/time column. For example, if you want to subtract 10 hours (or 10/24 for fractional days), you can create a calculated column like this:
```DAX
Adjusted Date/Time = YourTable[Original Date/Time] - TIME(10, 0, 0)
```
Replace "YourTable" and "Original Date/Time" with the appropriate table and column names.

3. **Consider Date/Time Dimension Tables**:
- A best practice in Power BI is to use a Date/Time dimension table that contains all possible date/time values you need. This table can include adjusted date/time columns. You can then establish relationships between your fact tables and this dimension table based on the date/time columns. This approach allows for consistent handling of date/time across multiple visuals.

4. **Verify Data Source Settings**:
- Check the data source settings for your data connection. Ensure that the date/time columns are correctly mapped to their respective data types and time zones. Depending on your data source, there may be settings that need to be adjusted.

5. **Scheduled Refresh and Time Zones**:
- If you're publishing to Power BI Service, keep in mind that the data source, Power BI Desktop, and Power BI Service should all be in sync regarding the time zone settings. Scheduled refreshes in Power BI Service might be influenced by the time zone settings of the Power BI Service workspace. Ensure these settings are consistent.

6. **Verify Data in Power BI Service**:
- After publishing, make sure to verify the data in Power BI Service to see if the date/time columns are displaying as expected. It's possible that the issue may not occur in the published version.

7. **Reach Out to Power BI Support**:
- If you've tried the above steps and are still facing issues, consider reaching out to Power BI Support for assistance.

[Jays_D]

Thank you @vs_7 ,

Your suggestions would solve if I was just starting a new dashboard, however this is an existing one with over 40 date columns, all of which are used on several other calculated & custom columns. 

Using suggestion 2 (Timezone Offset) would of been ideal if I could apply something like this across any/all existing date&time colums - however to create another 40+ columns to apply the offset and then re-create every associated calculated/custom columns is just not feasible.

It's a shame, the more I use Power BI, the more I see just how flawed it can be - applying something as important as showing the date and time in the correct format (as it is in source) should not be this complex, an issue I have not faced with Tableu - hoping Microsoft finds a way to address this.

I truly appreciate your response though, thank you !