MicrosoftWe've noticed an issue with our Windows-based Teams Rooms appliances, where the Teams Rooms interface displays the clock and meeting times one hour behind the actual BC time.
The issue appeared after our W11 IoT devices received the update and switched to the new BC time zone (UTC-07:00). We've confirmed that Windows itself displays the correct time and UTC-07:00 offset. However, the Teams Rooms application displays both the clock and scheduled meeting start/end times one hour behind (UTC-08:00).
Our Exchange Online resource mailboxes were originally configured with Pacific Standard Time. However, updating them to BC Standard Time, Yukon or US Mountain Standard Time (Arizona) did NOT resolve the issue, and the only workaround is to change the Windows time zone to Arizona or stay with Pacific Time (US & Canada).
Get-TimeZone shows the new BC Time to have BaseUtcOffset -08:00:00 and SupportsDaylightSavingTime set to True. I think this is for backward compat, but not working well with Teams.
Is there a minimum Microsoft Teams Rooms application version required to support the new BC time zone, or is there a known compatibility issue beyond the Windows/Exchange Online time zone configuration? Do we need to be on Arizona or Yukon time?
It looks like Microsoft has just published an advisory about this issue in the service health dashboard (TM1506929). There is a fixed version of WebView2 rolling out that should resolve this.
Edit: According to this Reddit post, the WebView2 update fixes an issue with the desktop Teams app but not the Teams Rooms issue.
Edit 2: The WebView2 update does fix the Teams Rooms issue as well.
I can confirm the recent update of WebView2 to .60 fixed the Teams’ chat timestamp. My machine got the update on 16 Oct evening. Theoretically if you close (Quit or totally kill Trams tasks) Teams or reboot your computer now and relaunch Teams the update should be pushed to your machine. Otherwise manual update using PS command per previous post in this forum.
It seems that the updates to Edge and WebView2 include new definitions to their bundled ICU libraries. This will work for applications that use those, but won't do anything for applications that rely on the system-provided ICU libraries or bundle their own outdated libraries. For example - the Edge and WebView2 updates will do nothing for FireFox (which bundles it's own ICU).
The ICU_TIMEZONE_FILES_DIR workaround should work for (nearly) all applications that use ICU (either bundled or system). I think this is the most reliable immediate fix, at least until everything else has been updated. It does mean that any future ICU timezone updates won't have any effect (unless you update your own .res files), so it would probably be best to remove the fix after Microsoft and others have updated everything.
EDIT: Firefox bundles it's own ICU, rather than using the system one. Either way, the ICU_TIMEZONE_FILES_DIR works. You can use process monitor and filter for things like "icu.dll", "icudtl.dat", and "windowsZones.res" to see what various applications on your system are using.
Edge, Chrome, Firefox, Teams Desktop, and likely many other applications show an time that is off by one hour. I have done a bunch of troubleshooting on this, and traced it down to ICU library issues (as mentioned earlier by GGrisAct3D). I have also come up with a fix.
Windows bundles ICU (International Components for Unicode) libraries. These libraries are used by many applications, including the ones listed above. Additionally, some applications bundle their own copies of ICU libraries.
One of things this library does is provide a mapping between windows time zones definitions and the IANA tzdb names (like "America/Vancouver"). In order to work properly, these mappings need to be updated to include the newly created time zones. The latest windows update does not include the updated mappings, nor does the latest tzdata "icunew" release from ICU (version 2026e).
It's possible to address this as follows:
This causes any applications using ICU to load the updated/custom definitions. Placing it under system32 is necessary to work with Firefox, otherwise Firefox's sandboxing will block access to the .res files. This fix may not work for UWP applications, applications that bundle ICU with compile time settings to disable external resource loading, or applications that bundle very old versions of ICU. I have tested it with Edge, Chrome, Firefox, and Teams Desktop - it worked for all of those.
