PBIRS Scheduled Refresh displays incorrect timestamp – one-hour discrepancy in LastRunTimeDescription

Question

PBIRS Scheduled Refresh displays incorrect timestamp – one-hour discrepancy in LastRunTimeDescription

Karduri, Naveen 0

Product:Power BI Report Server (On-premises)

Issue type: Technical / Break-fix

Description:

Following our recent server timezone configuration changes to use British Columbia local time, we noticed an inconsistency in the Scheduled Refresh timestamp displayed in the Power BI Report Server web portal.

The REST API returns the correct timestamp in the LastRunTime field, including the expected timezone offset. However, the corresponding LastRunTimeDescription field is consistently one hour behind.

Example REST API response:

json

{

"EventType": "DataModelRefresh",

"LastRunTime": "2026-11-03T20:04:38.647-07:00",

"LastRunTimeDescription": "Nov 03, 2026 7:04:38 PM"

}

Expected display: November 3, 2026, 8:04:38 PM.

Actual description: November 3, 2026, 7:04:38 PM.

Troubleshooting already completed:

Updated the Windows server timezone to British Columbia Standard Time.
Rebooted the PBIRS server after the timezone change.
Verified the .NET timezone using [TimeZoneInfo]::Local.
Verified Windows local time and UTC time.
Verified the browser timezone is America/Vancouver.
Confirmed JavaScript converts the ISO timestamp correctly to local time.
Queried the PBIRS REST API directly and confirmed that LastRunTime contains the expected timestamp.
Confirmed that LastRunTimeDescription contains a timestamp exactly one hour behind.

Expected behaviour:

Both LastRunTime and LastRunTimeDescription should represent the same local timestamp.

Actual behaviour:

The ISO timestamp and human-readable timestamp returned by the same REST API response differ by one hour.

We would also appreciate confirmation of whether any additional PBIRS configuration is required for British Columbia local timezone handling.

Power BI Report Server - Sep 2026 ( Version1.27.9794.1532(September 2026))

Regards,

Naveen

0 comments

2 answers

Your answer

Answer 1

The one-hour gap lines up exactly with British Columbia's time change. BC stayed on UTC-7 permanently from 1 November 2026 instead of falling back, and Microsoft added a separate Windows time zone for it in the September/October 2026 updates.

So your LastRunTime (20:04:38 -07:00) is the correct BC time. LastRunTimeDescription (7:04:38 PM) is the same instant converted with the old Pacific rules (UTC-8, as if clocks had fallen back on 1 November). The component that builds the description is still applying the old Pacific Standard Time rules somewhere.

Where to look

Step 1. The SQL Server that hosts the ReportServer catalog database. Scheduled refreshes run through SQL Server Agent on that instance, so its host's time zone and updates matter too, not just the PBIRS server. On that SQL Server, run:

SELECT SYSDATETIMEOFFSET() AS sql_now, CURRENT_TIMEZONE() AS sql_time_zone;

If it shows -08:00, or a time zone name other than BC's, that host is still on the old rules. It needs the update and the time zone change, then a restart of the SQL Server and SQL Server Agent services.

Step 2. The Windows update on every server involved (PBIRS and SQL Server). The BC rules come with the October 2026 monthly update, for example KB5126655 for Windows Server 2022 or KB5126646 for Windows Server 2025. On each server, check:

Get-TimeZone | Select-Object Id, DisplayName, BaseUtcOffset, SupportsDaylightSavingTime
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5

Id should be British Columbia Standard Time, and SupportsDaylightSavingTime should be False. A server that is still on Pacific Standard Time produces exactly the one-hour difference you're seeing.

Step 3. Restart all PBIRS services after the change. You've rebooted the PBIRS server, which covers its own services. If the catalog database is on a separate server, that one needs its own restart after Step 1.

If both servers show the BC zone with the update installed and the description is still an hour behind, PBIRS is likely formatting LastRunTimeDescription with its own time zone data. In that case, raise it with Microsoft support for PBIRS, quoting your REST API example. Until it's fixed, display times from LastRunTime (which carries the offset) rather than LastRunTimeDescription.

If this helps you find the cause, please consider marking it as the accepted answer so others with similar issue can find it.

Karduri, Naveen 0 Reputation points

2026-11-04T04:43:12.51+00:00

@Paul Thomas Thank you for your quick response

SELECT SYSDATETIMEOFFSET() AS sql_now, CURRENT_TIMEZONE() AS sql_time_zone;

2026-11-03 21:41:15.4996696 -07:00

(UTC-07:00) Pacific Time (British Columbia)

Get-TimeZone | Select-Object Id, DisplayName, BaseUtcOffset, SupportsDaylightSavingTime

Output:

Id DisplayName BaseUtcOffset SupportsDaylightSavingTime

British Columbia Standard Time (UTC-07:00) Pacific Time (British Columbia) -08:00:00 True

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5

KB5126651

KB5126650

KB5127685
Paul Thomas 80 Reputation points

2026-11-04T08:09:17.4166667+00:00

@Karduri, Naveen Thanks for running those, and a correction on my side: I was wrong that SupportsDaylightSavingTime should be False. Microsoft implemented BC's change as permanent daylight saving time, so a base offset of -08:00 with daylight saving that no longer ends is the expected shape for British Columbia Standard Time. Your results show both servers are set up correctly:

SQL Server returns -07:00 and "Pacific Time (British Columbia)".

Windows has the BC zone and the October update (KB5126651).

That rules out the server configuration. The remaining explanation is that PBIRS builds LastRunTimeDescription from time zone rules that don't know about the BC change: it gives exactly the old fall-back result (UTC-8), while LastRunTime carries the correct -07:00. I'd raise it with Microsoft support for Power BI Report Server, including:

your REST API example showing both fields

the PBIRS version (1.27.9794.1532, September 2026)

the outputs you just posted, which show that Windows and SQL Server already have the BC rules

Until there's a fix, display the time from LastRunTime, which includes the offset, rather than from LastRunTimeDescription.
Paul Thomas 80 Reputation points

2026-11-11T11:43:24.47+00:00

@Karduri, Naveen Were the refresh timestamps correct after the time zone fix? If they're showing the right time now, please mark the answer as accepted so others in British Columbia hitting the same thing can find it. If they're still an hour off, post what you see and I'll take another look.

Answer 2

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more