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

Update Value of TwoDigitYearMax to 2049 #76848

Merged
merged 17 commits into from
Oct 22, 2022
Merged

Update Value of TwoDigitYearMax to 2049 #76848

merged 17 commits into from
Oct 22, 2022

Conversation

cdbullard
Copy link
Contributor

Fix #75148

Update the century assumption cutoff year for determining whether a year is referring to a 19XX date or a 20XX date from 2029 to 2049.

@ghost ghost added the community-contribution Indicates that the PR has been added by a community member label Oct 11, 2022
@ghost
Copy link

ghost commented Oct 11, 2022

Tagging subscribers to this area: @dotnet/area-system-globalization
See info in area-owners.md if you want to be subscribed.

Issue Details

Fix #75148

Update the century assumption cutoff year for determining whether a year is referring to a 19XX date or a 20XX date from 2029 to 2049.

Author: cdbullard
Assignees: -
Labels:

area-System.Globalization

Milestone: -

@danmoseley
Copy link
Member

Tests are all under System.Globalization.Calendars. Search for "twodigityear" eg

Assert.True(calendar.TwoDigitYearMax == 2029 || calendar.TwoDigitYearMax == 2049, $"Unexpected calendar.TwoDigitYearMax {calendar.TwoDigitYearMax}");

@cdbullard
Copy link
Contributor Author

cdbullard commented Oct 11, 2022

Interestingly when I try to change this to 2049 and 2069, the unit test fails:

Assert.True(calendar.TwoDigitYearMax == 2029 || calendar.TwoDigitYearMax == 2049, $"Unexpected calendar.TwoDigitYearMax {calendar.TwoDigitYearMax}");

@danmoseley Just wanted to leave a note, this section is giving me trouble with updating the unit tests (and others seem to cause similar issues, even with the updated code). Do you have any advice?

@danmoseley
Copy link
Member

build failures are fixed by #76860

@tarekgh
Copy link
Member

tarekgh commented Oct 11, 2022

I am not seeing any change to read the two digits max settings when running on Windows (when using ICU).

I mean the code at

int twoDigitYearMax = GlobalizationMode.UseNls ? CalendarData.NlsGetTwoDigitYearMax(CalID) : CalendarData.IcuGetTwoDigitYearMax();

Need to change. Instead of branching for NLS and ICU cases, we need to branch it for Windows and non-Windows` case (with considering the special case of invariant mode).
So, on Windows we'll call

internal static int NlsGetTwoDigitYearMax(CalendarId calendarId)

and on none-Windows we'll do

Usually, we can have these two different implementations in CalendarData.Unix.cs and CalendarData.Windows.cs files.

@danmoseley
Copy link
Member

some extra context here @cdbullard, although you probably know

  • on non Windows, we use the ICU library for globalization settings. we don't read two digit year value from ICU, apparently it doesn't exist in ICU, so we use the hard coded default you changed.
  • on Windows we also use ICU, so again we have to use the hard coded default. however, you can switch your app to NLS mode if you want, and in this mode is needs to read the Windows setting you can change in the Window UI. This is the behavior today and should continue.

This has info on how to switch to NLS mode. Before your change, you should notice that in NLS mode, when you change the Windows two digit year value in the Windows UI, your C# code will see the change. That's the behavior that needs to stay.
https://learn.microsoft.com/en-US/dotnet/core/runtime-config/globalization

@@ -711,7 +712,7 @@ internal static long TimeToTicks(int hour, int minute, int second, int milliseco

internal static int GetSystemTwoDigitYearSetting(CalendarId CalID, int defaultYearValue)
{
int twoDigitYearMax = GlobalizationMode.UseNls ? CalendarData.NlsGetTwoDigitYearMax(CalID) : CalendarData.IcuGetTwoDigitYearMax();
int twoDigitYearMax = RuntimeInformation.IsOSPlatform(OSPlatform.Windows) ? CalendarData.NlsGetTwoDigitYearMax(CalID) : CalendarData.IcuGetTwoDigitYearMax();
Copy link
Member

Choose a reason for hiding this comment

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

Thanks @cdbullard for adding that. We usually avoid doing the OS checks inside the code. Instead we separate the code during compile time.

For this change, please move the method NlsGetTwoDigitYearMax to the file CalendarData.Windows.cs and rename the method to something like GetTwoDigitYearMax. Then move the method IcuGetTwoDigitYearMax to the file CalendarData.Unix.cs and rename the method to the same name GetTwoDigitYearMax (taking same parameters as the one moved to Windows file). last, make GetSystemTwoDigitYearSetting just CalendarData.GetTwoDigitYearMax.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for clarifying that for me. If I make the method GetSystemTwoDigitYearSetting like this:

internal static int GetSystemTwoDigitYearSetting(CalendarId CalID, int defaultYearValue)
{
    return CalendarData.GetTwoDigitYearMax(CalID);
}

should I also remove the defaultYearValue from the signature and from the places this method is being called?

Copy link
Member

Choose a reason for hiding this comment

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

No, please keep it as:

internal static int GetSystemTwoDigitYearSetting(CalendarId CalID, int defaultYearValue)
{
    int twoDigitYearMax = CalendarData.GetTwoDigitYearMax(CalID);
    return twoDigitYearMax >= 0 ? twoDigitYearMax : defaultYearValue;
}

Sorry I was not clear in that part :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks! I've just pushed a commit for this, let me know if any of it should be changed


// There is no user override for this value on Linux or in ICU.
// So just return -1 to use the hard-coded defaults.
return -1;
Copy link
Member

Choose a reason for hiding this comment

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

return -1;

Could you please change this to:

return GlobalizationMode.Invariant ? Invariant.iTwoDigitYearMax : -1;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure thing, this has been corrected

Copy link
Member

Choose a reason for hiding this comment

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

please check there's a test that reads this in invariant mode (ie that would fail without the change above)

@tarekgh
Copy link
Member

tarekgh commented Oct 12, 2022

@cdbullard I added one more little comment, LGTM otherwise. Let's see if all tests pass and then we merge it.

@danmoseley danmoseley added the breaking-change Issue or PR that represents a breaking API or functional change over a prerelease. label Oct 12, 2022
@danmoseley danmoseley added the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Oct 12, 2022
@ghost
Copy link

ghost commented Oct 12, 2022

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

  1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
  2. Ask a committer to mail the .NET Breaking Change Notification DL.

Breaking change doc

Tagging @dotnet/compat for awareness of the breaking change.

@tarekgh
Copy link
Member

tarekgh commented Oct 12, 2022

@cdbullard

src\libraries\System.Private.CoreLib\src\System\Globalization\CalendarData.Nls.cs(26,28): error CA1823: (NETCORE_ENGINEERING_TELEMETRY=Build) Unused field 'CAL_ITWODIGITYEARMAX'

please remove CAL_ITWODIGITYEARMAX from that file and ensure it is defined in the CalendarData.Windows.cs file.

@danmoseley
Copy link
Member

did you merge away some of your tests? I only see one


public override int TwoDigitYearMax
{
get
{
if (_twoDigitYearMax == -1)
{
_twoDigitYearMax = GetSystemTwoDigitYearSetting(BaseCalendarID, GetYear(new DateTime(DefaultGregorianTwoDigitYearMax, 1, 1)));
_twoDigitYearMax = GetSystemTwoDigitYearSetting(ID, DefaultGregorianTwoDigitYearMax);
Copy link
Member

Choose a reason for hiding this comment

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

Why did you change this? GetYear gets the year from the used calendar and not necessary to match the Gregorian year.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This change was discussed under this comment, but let me know if it was handled incorrectly in my commit

Copy link
Member

Choose a reason for hiding this comment

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

I replied to that comment. Please try to revert this change.

Copy link
Member

Choose a reason for hiding this comment

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

that was my bad.

@tarekgh tarekgh merged commit ebf4ea7 into dotnet:main Oct 22, 2022
@tarekgh
Copy link
Member

tarekgh commented Oct 22, 2022

Thanks @cdbullard for helping with this change!

@tarekgh tarekgh removed the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Oct 22, 2022
@tarekgh tarekgh added this to the 8.0.0 milestone Oct 22, 2022
@cdbullard
Copy link
Contributor Author

My pleasure @tarekgh! Will keep an eye out for more :-)

@cdbullard cdbullard deleted the twoyearvalue branch October 23, 2022 01:32
@ghost ghost locked as resolved and limited conversation to collaborators Nov 22, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Globalization breaking-change Issue or PR that represents a breaking API or functional change over a prerelease. community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consider increase to TwoDigitYearMax
4 participants