Blazor WASM .NET 5 TimeZoneInfo DaylightName values not correct

[jgilm]

Description

Using Blazor WASM with .NET 5, the information in TimeZoneInfo.DaylightName is incorrect and appears to mirror the TimeZoneInfo.StandardName.

Actual Behavior:

TimeZoneInfo.DaylightName is identical to TimeZoneInfo.StandardName.
For example using this code

                @foreach (var tz in TimeZoneInfo.GetSystemTimeZones().OrderBy(tz => tz.BaseUtcOffset))
                {
                    <tr>
                        <td>@tz.Id</td><td>@tz.DisplayName</td><td>@tz.StandardName</td>
                        <td>@tz.SupportsDaylightSavingTime</td><td>@tz.DaylightName</td>
                        <td>@tz.BaseUtcOffset</td>
                    </tr>
                }

produces

Expected Behavior:

TimeZoneInfo.DaylightName is different (and correct) for time zones that support daylight saving time.
For example, in a .NET 5 console application the same values look like this:

Pacific Standard time in a .NET 5 console app shows that the StandardName is "Pacific Standard Time" and the DaylightName is "Pacific Daylight Time"

This may be partially related to #44840

Configuration

• NET 5
• Blazor WASM
• Windows 10
• Chrome 86
• Project settings looks like this:

  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
    <ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest>
    <BlazorWebAssemblyLoadAllGlobalizationData>true</BlazorWebAssemblyLoadAllGlobalizationData>
  </PropertyGroup>

Regression?

This is a regression from Blazor WASM 3.2, which produces this result

Other information

• I realize the time zone source may have changed, but the DisplayName field seems clunky as well compared to the Blazor WASM 3.2 version.
• Along with TimeZoneInfo.GetSystemTimeZones produces unexpected results in Blazor WASM for .NET 5 #44840. even with the project setting of <BlazorWebAssemblyLoadAllGlobalizationData>true</BlazorWebAssemblyLoadAllGlobalizationData> I can only get 14 time zones to display, and they are seemingly random.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @tarekgh, @safern, @krwq
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Using Blazor WASM with .NET 5, the information in TimeZoneInfo.DaylightName is incorrect and appears to mirror the TimeZoneInfo.StandardName.

Actual Behavior:

TimeZoneInfo.DaylightName is identical to TimeZoneInfo.StandardName.
For example using this code

                @foreach (var tz in TimeZoneInfo.GetSystemTimeZones().OrderBy(tz => tz.BaseUtcOffset))
                {
                    <tr>
                        <td>@tz.Id</td><td>@tz.DisplayName</td><td>@tz.StandardName</td>
                        <td>@tz.SupportsDaylightSavingTime</td><td>@tz.DaylightName</td>
                        <td>@tz.BaseUtcOffset</td>
                    </tr>
                }

produces

Expected Behavior:

TimeZoneInfo.DaylightName is different (and correct) for time zones that support daylight saving time.
For example, in a .NET 5 console application the same values look like this:

Pacific Standard time in a .NET 5 console app shows that the StandardName is "Pacific Standard Time" and the DaylightName is "Pacific Daylight Time"

This may be partially related to #44840

Configuration

• NET 5
• Blazor WASM
• Windows 10
• Chrome 86
• Project settings looks like this:

  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
    <ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest>
    <BlazorWebAssemblyLoadAllGlobalizationData>true</BlazorWebAssemblyLoadAllGlobalizationData>
  </PropertyGroup>

Regression?

This is a regression from Blazor WASM 3.2, which produces this result

Other information

• I realize the time zone source may have changed, but the DisplayName field seems clunky as well compared to the Blazor WASM 3.2 version.
• Along with TimeZoneInfo.GetSystemTimeZones produces unexpected results in Blazor WASM for .NET 5 #44840. even with the project setting of <BlazorWebAssemblyLoadAllGlobalizationData>true</BlazorWebAssemblyLoadAllGlobalizationData> I can only get 14 time zones to display, and they are seemingly random.

Author:	jgilm
Assignees:	-
Labels:	arch-wasm, area-System.Globalization, untriaged
Milestone:	-

[marek-safar]

/cc @lewing

[lewing]

@tqiu8 can you test the example on unix as well and make sure all the other issues are already tracked/resolved

[radical]

Just curious, do we have tests for this?

[safern]

Just curious, do we have tests for this?

I just searched for that and it seems like we don't for WASM, the one we have uses RemoteExecutor, hence it is skipped on WASM.

[lewing]

Looks like there is some crossover here with #16232 ?

[tqiu8]

Yea it looks like the DaylightName and StandardName are the same in unix. Also the display name is basically of the format (UTC+<diff>) StandardName as well

[lewing]

I think we've found the issue with DaylightName and a fix is in progress. The StandardName/DisplayName commonality is #16232
It is different from 3.2 because the core libraries have changed.

[tarekgh]

@lewing how did we use to get the display name in 3.2? did we carry the data back then?

[lewing]

@tarekgh I haven't verified the code but 3.2 Wasm used the mono/mono bcl with different timezone code which likely carried this data with it for compatibility with windows. I can double check next week.