Skip to content

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

Closed
@tarekgh

Description

@tarekgh

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

Metadata

Metadata

Assignees

Labels

🏁 Release: .NET 8Work items for the .NET 8 release📌 seQUESTeredIdentifies that an issue has been imported into Quest.breaking-changeIndicates a .NET Core breaking change

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions