Forum Discussion

Nagaraj_D's avatar
Nagaraj_D
Advocate I
7 months ago
Solved

Dynamic User Time Zone Datetime Conversion in Power BI Embedded

Hi all, I have been looking into datetime conversion solution in Power BI Report for both direct query and import mode storage. I'm Embedding these report into my web application with Embed for Cus...
  • pankajnamekar25's avatar
    7 months ago

    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:

    LinkedIn

     

  • v-veshwara-msft's avatar
    v-veshwara-msft
    7 months ago

    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.