Forum Discussion
Dynamic User Time Zone Datetime Conversion in Power BI Embedded
Hello Nagaraj_D
Try these
Store all datetimes in UTC in the source and model.
Do NOT convert time zones in Power Query for multi-user embedded reports.
Use DAX-based conversion at visual/query time using:
Disconnected Dim_User_TimeZone
RLS or Embed token (per user)
DST logic in measures
Accept that measures can’t be used on slicers/axes.
If my response helped you, please consider clicking
Accept as Solution ✅ and giving it a Like 👍 – it helps others in the community too.
Thanks,
Connect with me on:
LinkedInHi Nagaraj_D ,
Thanks for posting this in the community and for clearly explaining your approach and the observations you made.
As already mentioned by mohit_sakhare and pankajnamekar25 in the earlier responses, keeping all datetimes in UTC and handling per user timezone conversion at query or visual time using DAX is the recommended pattern, with the known limitation that measures cannot be used on slicers or axes.
To specifically address the behavior you observed with the measure based datetime on drillthrough, this is expected. Measures do not define row level granularity in table or matrix visuals. When multiple underlying UTC rows evaluate to the same values for all visible columns and the datetime is provided only through a measure, Power BI groups those rows at render time. That is why the count is correct on the summary page, but the detail table can appear blank unless a physical column that preserves row uniqueness is present.
Including a unique identifier such as the call tracking ID, or keeping the original UTC datetime column for row grain and drillthrough while using the localized datetime measure only for display, is the correct and supported way to handle this.
Hope this helps. Please reach out for further assistance.
Thank you.
Hi mohit_sakhare ,
Thanks for the detailed information.
I tested the shared dataset using the dynamic parameter approach in an embed scenario and confirmed that the DateTime columns are converted correctly based on the user’s time zone.
I will also try the approach you mentioned using a disconnected table and will share my observations afterward.
Regarding the measure-based approach, first thing is that I had hardcoded the time zone abbreviations [need more dynamic way of doing it.], and one more thing i forgot to metion earlier as I encountered a row count mismatch in a table visual.
For example:
this is the table expected
mbridn name addr caller calldate[utc]
101 ABC addr1 caller1 2025-10-01 10:30:00 AM
101 ABC addr1 caller1 2025-10-02 10:30:00 AM
101 ABC addr1 caller1 2025-10-03 10:30:00 AM
example: in main page if i show the count as 3 and user will drillthrough from this count and navigate to detail report page but user will see blank table visual.
if we use measure for calldate with timezone IST
idn name addr caller calldate[measure]
since all column values are same for that member in table visual shows blank. here instead if i try to bring utc column able to see all three rows.
Currently added the distinct idn column in detail report page table visual and wrapped that column as user can't see but while export they can.I’d appreciate it if the community could share their thoughts or suggestions on this observation with the measure-based approach, and whether this behavior is expected or if there are recommended ways to handle it more effectively.
Thanks in advance!
Hi Nagaraj_D ,
Thanks for posting this in the community and for clearly explaining your approach and the observations you made.
As already mentioned by mohit_sakhare and pankajnamekar25 in the earlier responses, keeping all datetimes in UTC and handling per user timezone conversion at query or visual time using DAX is the recommended pattern, with the known limitation that measures cannot be used on slicers or axes.
To specifically address the behavior you observed with the measure based datetime on drillthrough, this is expected. Measures do not define row level granularity in table or matrix visuals. When multiple underlying UTC rows evaluate to the same values for all visible columns and the datetime is provided only through a measure, Power BI groups those rows at render time. That is why the count is correct on the summary page, but the detail table can appear blank unless a physical column that preserves row uniqueness is present.
Including a unique identifier such as the call tracking ID, or keeping the original UTC datetime column for row grain and drillthrough while using the localized datetime measure only for display, is the correct and supported way to handle this.
Hope this helps. Please reach out for further assistance.
Thank you.
Hi Nagaraj_D ,
Just checking back to see if the explanation above helps clarify the behavior you observed with the measure based approach. Let us know if you have any follow up questions or if you’d like to explore alternative patterns further.Thank you.
Hi Nagaraj_D ,
Just checking in to see if the earlier responses helped address your question. Please let us know if you need any further clarification.Thank you.