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

[Breaking change]: TwoDigitYearMax default value changed from 2029 to 2049 in Gregorian based calendars #31978

Closed
2 tasks
tarekgh opened this issue Oct 22, 2022 · 0 comments · Fixed by #33718
Closed
2 tasks
Assignees
Labels
breaking-change Indicates a .NET Core breaking change 🏁 Release: .NET 8 Work items for the .NET 8 release doc-idea Indicates issues that are suggestions for new topics [org][type][category] Pri1 High priority, do before Pri2 and Pri3 📌 seQUESTered Identifies that an issue has been imported into Quest.

Comments

@tarekgh
Copy link
Member

tarekgh commented Oct 22, 2022

Description

Calendars has the TwoDigitYearMax property which defines the last year of a 100-year range that can be represented by a 2-digit year. This property is usually used when having 2-digits years which need to be translated to the 4-digits years. This property used to be defaulted inside the Gregorian based calendars to 2029 which translate 2-digit years from 00 to 29 to be 2000 to 2029 as a 4-digits year. Any year from 30 to 99 will be translated into 1930 to 1999. The breaking change is changing the default property value from 2029 to 2049. Which means it translates 2-digit years from 00 to 49 to be 2000 to 2049 as a 4-digits year. Any year from 50 to 99 will be translated into 1950 to 1999.

Also, when running on Windows, we'll start to get the default value of the TwoDigitYearMax property from Windows settings as we are doing that on .NET Framework. Also, we used to read Windows settings on NET Core up to and including version 3.1 till we switched to use ICU in .NET 5.0. Date parsing is the functionality which is the most affected by this change.

dotnet/runtime#75148
dotnet/runtime#76848

Version

.NET 8 Preview 1

Previous behavior

If not overriding the value of this property and trying to parse a date like 12/25/35 with Gregorian calendar, it used to produce the date December 12, 1935. This behavior will be observed on .NET 6.0 and 7.0.

New behavior

After the change parsing dates like 12/25/35 will produce the date December 12, 2035. This new behavior will be observed starting of .NET 8.0.

Type of breaking change

  • Binary incompatible: Existing binaries may encounter a breaking change in behavior, such as failure to load/execute or different run-time behavior.
  • Source incompatible: Source code may encounter a breaking change in behavior when targeting the new runtime/component/SDK, such as compile errors or different run-time behavior.

Reason for change

We are already in the year 2022. It makes more sense when parsing 2-digit years closer to current year will produce 4-digit years in current century and not the previous one. Windows OS changed its default settings too to same number 2049.

Recommended action

Any app not desiring to depend on the default settings when parsing and want to control the 2-digit year translation to 4-digit year, can do that by setting the desired value to TwoDigitYearMax.

CultureInfo clonedInvariantCulture = (CultureInfo)(CultureInfo.InvariantCulture.Clone());
clonedInvariantCulture.DateTimeFormat.Calendar.TwoDigitYearMax = 2039; // any desired cutoff value

DateTime dt = DateTime.Parse("12/25/35", clonedInvariantCulture);

Feature area

Globalization

Affected APIs

Calendars and Date parsing APIs.


Associated WorkItem - 60878

@tarekgh tarekgh added doc-idea Indicates issues that are suggestions for new topics [org][type][category] breaking-change Indicates a .NET Core breaking change Pri1 High priority, do before Pri2 and Pri3 labels Oct 22, 2022
@dotnet-bot dotnet-bot added the ⌚ Not Triaged Not triaged label Oct 22, 2022
@gewarren gewarren added 🏁 Release: .NET 8 Work items for the .NET 8 release and removed ⌚ Not Triaged Not triaged labels Oct 24, 2022
@gewarren gewarren added the 🗺️ reQUEST Triggers an issue to be imported into Quest. label Jan 10, 2023
@ghost ghost added the in-pr This issue will be closed (fixed) by an active pull request. label Jan 26, 2023
@github-actions github-actions bot added 📌 seQUESTered Identifies that an issue has been imported into Quest. and removed 🗺️ reQUEST Triggers an issue to be imported into Quest. labels Jan 26, 2023
@gewarren gewarren moved this from 🔖 Ready to 🏗 In progress in dotnet/docs January 2023 sprint Jan 26, 2023
@github-project-automation github-project-automation bot moved this from 🏗 In progress to ✅ Done in dotnet/docs January 2023 sprint Jan 26, 2023
@ghost ghost removed the in-pr This issue will be closed (fixed) by an active pull request. label Jan 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change Indicates a .NET Core breaking change 🏁 Release: .NET 8 Work items for the .NET 8 release doc-idea Indicates issues that are suggestions for new topics [org][type][category] Pri1 High priority, do before Pri2 and Pri3 📌 seQUESTered Identifies that an issue has been imported into Quest.
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants