Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[wasm] Use timezone abbreviations as fallback if full names don't exist #45385

Merged
merged 10 commits into from
Mar 5, 2021

Conversation

tqiu8
Copy link
Contributor

@tqiu8 tqiu8 commented Nov 30, 2020

Fixes: #45136

Uses Timezone abbreviations as a fallback if full name does not exist in the ICU. Added 2 browser tests for daylight name and standard names.

@Dotnet-GitSync-Bot
Copy link
Collaborator

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

@tqiu8
Copy link
Contributor Author

tqiu8 commented Nov 30, 2020

@EgorBo Currently this doesn't work yet because ucal_getTimeZoneDisplayName from the icu doesn't return anything. Is it possible that the timezone display names have been filtered out? All standard, generic, and display names are being returned as empty even though the result code is successful.

@tqiu8 tqiu8 changed the title use unix ver of GetDisplayName instead of invariant display name [wasm] Use unix ver of GetDisplayName instead of invariant display name Nov 30, 2020
<Compile Include="$(MSBuildThisFileDirectory)System\IO\DriveInfoInternal.Browser.cs" />
<Compile Include="$(MSBuildThisFileDirectory)System\IO\PersistedFiles.Browser.cs" />
<Compile Include="$(MSBuildThisFileDirectory)System\TimeZoneInfo.GetDisplayName.Invariant.cs" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Delete this file since it is no longer used? Also, TimeZoneInfo.GetDisplayName.cs can be merged back into TimeZoneInfo.GetDisplayName.Unix.cs.

@radical
Copy link
Member

radical commented Dec 1, 2020

This needs tests. And can you reference the issue, if any, that this is fixing?

@radical radical added the arch-wasm WebAssembly architecture label Dec 17, 2020
Copy link
Member

@lewing lewing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds like the invariant version was added when we didn't have full icu working. If browser is the only one using it we should go ahead and remove it. If you add a test we can verify it on desktop and compare to the wasm results.

@tqiu8 tqiu8 marked this pull request as ready for review January 12, 2021 19:59
@tqiu8 tqiu8 changed the title [wasm] Use unix ver of GetDisplayName instead of invariant display name [wasm] Use timezone abbreviations as fallback if full names don't exist Jan 12, 2021
@tqiu8 tqiu8 requested review from radical and EgorBo January 12, 2021 20:02
tqiu8 and others added 2 commits January 12, 2021 15:56
.. to abbreviations.

[This code](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Private.CoreLib/src/System/TimeZoneInfo.GetDisplayName.cs#L29-L40) seems to return `true` result, even though `timeZoneDisplayName` is null/empty. So, in such a case don't set the out var
and let the abbrev get used as the fallback (like it already says in the
comment).
@radical
Copy link
Member

radical commented Jan 13, 2021

The code here isn't completely correct. Eg. for Newfoundland, the display name would be "(UTC-03:30) ", instead of "(UTC-03:30) NST".

I have reworked the tests a bit too. The final diff would be master...radical:rf-tz-displayname-fix , with my additional commit - radical@1805c6d

<Compile Include="$(CommonPath)Interop\Interop.TimeZoneInfo.cs" Condition="'$(TargetsBrowser)' != 'true'">
<Compile Include="$(CommonPath)Interop\Interop.TimeZoneInfo.cs">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this changed needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because we aren't using TimeZoneInfo.GetDisplayName.Invariant.cs anymore (will also remove that file in this PR) so Interop.Globalization is not defined for Browser

@tqiu8
Copy link
Contributor Author

tqiu8 commented Jan 13, 2021

@radical The regex in the original form is actually incorrect. "^\(UTC(\+|-)[0-9]{2}:[0-9]{2}\) \S.*" is looking for a space after (UTC-03:30). Even though ((UTC-03:30) may not contain any more text afterwards.

@radical
Copy link
Member

radical commented Jan 13, 2021

@radical The regex in the original form is actually incorrect. "^\(UTC(\+|-)[0-9]{2}:[0-9]{2}\) \S.*" is looking for a space after (UTC-03:30). Even though ((UTC-03:30) may not contain any more text afterwards.

That was the case because the change in this PR set the display name (when falling back on abbreviation) after that string was constructed, so it ends up with nothing after the (UTC+03:30) - https://github.com/dotnet/runtime/pull/45385/files#diff-08facbdd1840bc8f2298563a79fe4565de02c874d72d7ac944890f8c4d200659R87-R93

See my changes, and the test: https://github.com/radical/runtime/blob/rf-tz-displayname-fix/src/libraries/System.Runtime/tests/System/TimeZoneInfoTests.cs#L90-L96

.. these have content after that space.

[wasm] If standard, or daylight names are not available, then fallback
@radical radical requested review from lewing and jkotas January 13, 2021 02:27
@lewing lewing requested a review from tarekgh January 21, 2021 20:59
@lewing
Copy link
Member

lewing commented Feb 18, 2021

The change makes sense, but are there any tests that check the daylight name on desktop?

@tqiu8
Copy link
Contributor Author

tqiu8 commented Feb 18, 2021

The change makes sense, but are there any tests that check the daylight name on desktop?

Only this one, so nothing comprehensive

Copy link
Member

@lewing lewing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add tests for the non browser case too then

};
}

[ConditionalTheory(typeof(PlatformDetection), nameof(PlatformDetection.IsBrowser))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of checking PlatformDetection.IsBrowser here can you make a Platform_TimeZoneNamesTestData that returns different data for IsBrowser so that we are testing both cases and verify that we haven't regressed the normal case?

Base automatically changed from master to main March 1, 2021 09:07
@tqiu8
Copy link
Contributor Author

tqiu8 commented Mar 4, 2021

Test failures unrelated to this change.

@tqiu8 tqiu8 requested review from lewing and radical March 4, 2021 18:00
Copy link
Member

@lewing lewing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!


[Theory]
[MemberData(nameof(Platform_TimeZoneNamesTestData))]
[PlatformSpecific(TestPlatforms.AnyUnix)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does windows have names for these extra timezones?

Copy link
Contributor

@mattjohnsonpint mattjohnsonpint Mar 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, assuming the OS platform language (not necessarily CurrentUICulture) is English, they would be:

{ TimeZoneInfo.FindSystemTimeZoneById(s_strPacific), "(UTC-08:00) Pacific Time (US & Canada)", "Pacific Standard Time", "Pacific Daylight Time" },
{ TimeZoneInfo.FindSystemTimeZoneById(s_strSydney), "(UTC+10:00) Canberra, Melbourne, Sydney", "AUS Eastern Standard Time", "AUS Eastern Daylight Time" },
{ TimeZoneInfo.FindSystemTimeZoneById(s_strPerth), "(UTC+08:00) Perth", "W. Australia Standard Time", "W. Australia Daylight Time" },
{ TimeZoneInfo.FindSystemTimeZoneById(s_strIran), "(UTC+03:30) Tehran", "Iran Standard Time", "Iran Daylight Time" },
{ s_NewfoundlandTz, "(UTC-03:30) Newfoundland", "Newfoundland Standard Time", "Newfoundland Daylight Time" },
{ s_catamarcaTz, "(UTC-03:00) City of Buenos Aires", "Argentina Standard Time", "Argentina Daylight Time" }

@lewing lewing merged commit 5d6c8aa into dotnet:main Mar 5, 2021
{ TimeZoneInfo.FindSystemTimeZoneById(s_strPacific), "(UTC-08:00) Pacific Standard Time", "Pacific Standard Time", "Pacific Daylight Time" },
{ TimeZoneInfo.FindSystemTimeZoneById(s_strSydney), "(UTC+10:00) Australian Eastern Standard Time", "Australian Eastern Standard Time", "Australian Eastern Daylight Time" },
{ TimeZoneInfo.FindSystemTimeZoneById(s_strPerth), "(UTC+08:00) Australian Western Standard Time", "Australian Western Standard Time", "Australian Western Daylight Time" },
{ TimeZoneInfo.FindSystemTimeZoneById(s_strIran), "(UTC+03:30) +0330", "+0330", "+0430" },
Copy link
Contributor

@mattjohnsonpint mattjohnsonpint Mar 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the last three be the full names from ICU?

{ TimeZoneInfo.FindSystemTimeZoneById(s_strIran), "(UTC+03:30) Iran Standard Time", "Iran Standard Time", "(UTC+03:30) Iran Standard Time" },
{ s_NewfoundlandTz, "(UTC-03:30) Newfoundland Standard Time", "Newfoundland Standard Time", "(UTC-03:30) Newfoundland Standard Time" },
{ s_catamarcaTz, "(UTC-03:00) Argentina Standard Time", "Argentina Standard Time", "(UTC-03:00) Argentina Standard Time" }

(Sorry I didn't see this earlier)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How did the test pass with the wrong values?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you referring to the last value in each test? They're supposed to be the DaylightNames.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I meant that in the non-browser version, the last three rows were not using the ICU names. I believe its due to the if (PlatformDetection.IsBrowser) in the test - this part of the test isn't being run. Per our offline discussion, I'll fix that up in my PR.

@tarekgh
Copy link
Member

tarekgh commented Mar 5, 2021

@mattjohnsonpint if you can fix such issues in your PR would be great. You are touching the same area anyway.

@mattjohnsonpint
Copy link
Contributor

Will do.

@lewing
Copy link
Member

lewing commented Mar 5, 2021

Thanks for following up on that, I should have caught it.

@ghost ghost locked as resolved and limited conversation to collaborators Apr 4, 2021
@karelz karelz added this to the 6.0.0 milestone May 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Blazor WASM .NET 5 TimeZoneInfo DaylightName values not correct
8 participants