Forum Discussion
Power BI Service Excel Export Fails When Using System.TimeZoneInfo.ConvertTimeFromUtc in RDL Express
I have an RDL file with approximately 800,000 rows. When I use the following expression in a textbox, I can successfully export the report to Excel from the Power BI Service:
="Number of rows exported: " & Format(CountRows("dsMain"), "#,##0") & vbCrLf & "Selected Period: " & Format(Parameters!pForecastPeriod.Value, "MM-dd-yyyy") & vbCrLf & "Generated On: " & Format(CDate(First(Fields!GENERATED_ON.Value, "dsMain")), "dd-MMM-yyyy hh:mm tt")
However, when I replace it with the following expression:
="Number of rows exported: " & Format(CountRows("dsMain"), "#,##0") & vbCrLf & "Selected Period: " & Format(Parameters!pForecastPeriod.Value, "MM-dd-yyyy") & vbCrLf & "Generated On: " & Format( System.TimeZoneInfo.ConvertTimeFromUtc( System.DateTime.UtcNow, System.TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time") ), "dd-MMM-yyyy hh:mm tt" ) & " PST"
the behavior changes:
- The report still exports successfully from Power BI Report Builder.
- However, when exporting from the Power BI Service, the export fails after approximately 2–3 minutes with an "Export failed" error.
Is there a known limitation with using System.TimeZoneInfo.ConvertTimeFromUtc or System.DateTime.UtcNow in Power BI Service paginated reports during export? If so, is there a recommended workaround that allows me to display the current time in PST while still allowing the report to export successfully from the Power BI Service?
This is most likely due to a Power BI Service sandbox limitation rather than an issue with your expression itself.
System.TimeZoneInfo.FindSystemTimeZoneById() and System.TimeZoneInfo.ConvertTimeFromUtc() rely on the underlying .NET runtime and Windows time zone registry. In Power BI Report Builder (running locally), these APIs have access to the local OS configuration, so the export succeeds. However, in the Power BI Service, paginated reports run in a managed environment where certain .NET methods and time zone resources may not be fully supported during rendering/export, which can lead to the generic "Export failed" error.
As a workaround, instead of using:
System.TimeZoneInfo.ConvertTimeFromUtc(
System.DateTime.UtcNow,
System.TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time")
)you could:
- Use a dataset field (GENERATED_ON) populated by SQL and perform the timezone conversion in the query itself:
SELECT SYSDATETIMEOFFSET() AT TIME ZONE 'Pacific Standard Time' AS GENERATED_ON_PST
- Or, if DST handling is not critical, use a simple offset:
=Format(DateAdd("h", -8, System.DateTime.UtcNow),
"dd-MMM-yyyy hh:mm tt") & " PST"- Another option is to use the built-in report execution time:
=Format(Globals!ExecutionTime,
"dd-MMM-yyyy hh:mm tt")and convert it in the source query if a specific timezone is required.
I'd recommend moving the timezone conversion to the data source (SQL) whenever possible, as it's generally more reliable for Power BI Service exports and avoids differences between the local Report Builder environment and the Service rendering engine.
Has anyone else seen TimeZoneInfo methods fail specifically during Power BI Service Excel exports? It would be interesting to know whether this is an undocumented limitation or a recent regression.
7 Replies
- I would not treat this as a confirmed unsupported expression yet.To isolate it, create a small test version of the report with the same expression but only a few rows. If that exports successfully from the Power BI Service, then the expression is probably valid, but it is causing problems during the large Excel render.The safest workaround is to avoid evaluating the timezone conversion directly in the textbox during export.Option 1:Calculate the generated timestamp in the dataset/source query and return it as a field.Option 2:Calculate it once in a report variable or hidden parameter, then only reference that value in the textbox.That keeps the Excel render expression simple, which is safer for a large export.
Best regards,
Solutions Architect · Microsoft Fabric Specialist · Parchitect💡Did my response help you? Clicking Kudos is a small gesture that goes a long way, it encourages contributors and helps the community thrive!
✔️Did I answer your question? Please mark my post as a Solution, it helps others find the answer faster.I tried everything from the solution, still it didn't work.
This is most likely due to a Power BI Service sandbox limitation rather than an issue with your expression itself.
System.TimeZoneInfo.FindSystemTimeZoneById() and System.TimeZoneInfo.ConvertTimeFromUtc() rely on the underlying .NET runtime and Windows time zone registry. In Power BI Report Builder (running locally), these APIs have access to the local OS configuration, so the export succeeds. However, in the Power BI Service, paginated reports run in a managed environment where certain .NET methods and time zone resources may not be fully supported during rendering/export, which can lead to the generic "Export failed" error.
As a workaround, instead of using:
System.TimeZoneInfo.ConvertTimeFromUtc(
System.DateTime.UtcNow,
System.TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time")
)you could:
- Use a dataset field (GENERATED_ON) populated by SQL and perform the timezone conversion in the query itself:
SELECT SYSDATETIMEOFFSET() AT TIME ZONE 'Pacific Standard Time' AS GENERATED_ON_PST
- Or, if DST handling is not critical, use a simple offset:
=Format(DateAdd("h", -8, System.DateTime.UtcNow),
"dd-MMM-yyyy hh:mm tt") & " PST"- Another option is to use the built-in report execution time:
=Format(Globals!ExecutionTime,
"dd-MMM-yyyy hh:mm tt")and convert it in the source query if a specific timezone is required.
I'd recommend moving the timezone conversion to the data source (SQL) whenever possible, as it's generally more reliable for Power BI Service exports and avoids differences between the local Report Builder environment and the Service rendering engine.
Has anyone else seen TimeZoneInfo methods fail specifically during Power BI Service Excel exports? It would be interesting to know whether this is an undocumented limitation or a recent regression.
Thank you for your respnse.
I will try this and get back to you.Hi PowerBI_freak_1,
Thank you for reaching out to the Microsoft Fabric Community Forum.Thanks for the update. Since the export to excel is still failing, you could try a small test to narrow it down. Create a simple paginated report with just a few rows and a textbox that uses only the System.TimeZoneInfo.ConvertTimeFromUtc(...) expression, then export it to Excel from the Power BI Service. If that works, it would suggest the issue is specific to the original report rather than the expression itself.
You could also try using just System.DateTime.UtcNow without the timezone conversion. That should help determine whether the issue is related to the timezone conversion or simply evaluating the current time in the report expression. If it still fails even in a simple report, it would suggest the issue isn't specific to your report design and may require further investigation as a service-side behavior.
Thanks and Regards.Hi PowerBI_freak_1,
Could you please confirm whether the issue has been resolved or is still occurring? Your update may help others with similar concerns. Please let us know if you need any further assistance.
Thank you.Hi PowerBI_freak_1 ,
Could you please confirm whether the provided solution helped in resolving the issue. If you have any further questions please feel free to reach out to us.
Thanks!!
