Skip to content
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion xml/System.Globalization/Calendar.xml
Original file line number Diff line number Diff line change
Expand Up @@ -2528,7 +2528,7 @@ Only the <xref:System.Globalization.JapaneseCalendar> and the <xref:System.Globa
- The <xref:System.Globalization.DateTimeFormatInfo.CalendarWeekRule?displayProperty=nameWithType> property contains the default calendar week rule that can be used for the `rule` parameter.

> [!NOTE]
> This does not map exactly to ISO 8601. The differences are discussed in the blog entry [ISO 8601 Week of Year format in Microsoft .NET](https://learn.microsoft.com/archive/blogs/shawnste/iso-8601-week-of-year-format-in-microsoft-net). Starting with .NET Core 3.0, <xref:System.Globalization.ISOWeek.GetYear*?displayProperty=nameWithType> and <xref:System.Globalization.ISOWeek.GetWeekOfYear*?displayProperty=nameWithType> solve this problem.
> This does not map exactly to ISO 8601. The differences are discussed in the blog entry [ISO 8601 Week of Year format in Microsoft .NET](https://learn.microsoft.com/archive/blogs/shawnste/iso-8601-week-of-year-format-in-microsoft-net). <xref:System.Globalization.ISOWeek.GetYear*?displayProperty=nameWithType> and <xref:System.Globalization.ISOWeek.GetWeekOfYear*?displayProperty=nameWithType> solve this problem.

The following example uses the current culture's <xref:System.Globalization.DateTimeFormatInfo> object to determine that January 1, 2011 is in the first week of the year in the Gregorian calendar.

Expand Down
2 changes: 1 addition & 1 deletion xml/System.Globalization/CalendarWeekRule.xml
Original file line number Diff line number Diff line change
Expand Up @@ -108,7 +108,7 @@
:::code language="vb" source="~/snippets/visualbasic/System.Globalization/CalendarWeekRule/Overview/calendarweekruleex.vb" id="Snippet1":::

> [!NOTE]
> This does not map exactly to ISO 8601. The differences are discussed in the blog entry [ISO 8601 Week of Year format in Microsoft .NET](https://learn.microsoft.com/archive/blogs/shawnste/iso-8601-week-of-year-format-in-microsoft-net). Starting with .NET Core 3.0, <xref:System.Globalization.ISOWeek.GetYear*?displayProperty=nameWithType> and <xref:System.Globalization.ISOWeek.GetWeekOfYear*?displayProperty=nameWithType> solve this problem.
> This does not map exactly to ISO 8601. The differences are discussed in the blog entry [ISO 8601 Week of Year format in Microsoft .NET](https://learn.microsoft.com/archive/blogs/shawnste/iso-8601-week-of-year-format-in-microsoft-net). <xref:System.Globalization.ISOWeek.GetYear*?displayProperty=nameWithType> and <xref:System.Globalization.ISOWeek.GetWeekOfYear*?displayProperty=nameWithType> solve this problem.

Each <xref:System.Globalization.CultureInfo> object supports a set of calendars. The <xref:System.Globalization.CultureInfo.Calendar> property returns the default calendar for the culture, and the <xref:System.Globalization.CultureInfo.OptionalCalendars> property returns an array containing all the calendars supported by the culture. To change the calendar used by a <xref:System.Globalization.CultureInfo>, set the <xref:System.Globalization.DateTimeFormatInfo.Calendar> property of <xref:System.Globalization.CultureInfo.DateTimeFormat*?displayProperty=nameWithType> to a new <xref:System.Globalization.Calendar>.

Expand Down
20 changes: 1 addition & 19 deletions xml/System.Globalization/CharUnicodeInfo.xml
Original file line number Diff line number Diff line change
Expand Up @@ -75,25 +75,19 @@
Use the <xref:System.Globalization.CharUnicodeInfo> class to obtain the <xref:System.Globalization.UnicodeCategory> value for a specific character. The <xref:System.Globalization.CharUnicodeInfo> class defines methods that return the following Unicode character values:

- The specific category to which a character or surrogate pair belongs. The value returned is a member of the <xref:System.Globalization.UnicodeCategory> enumeration.

- Numeric value. Applies only to numeric characters, including fractions, subscripts, superscripts, Roman numerals, currency numerators, encircled numbers, and script-specific digits.

- Digit value. Applies to numeric characters that can be combined with other numeric characters to represent a whole number in a numbering system.

- Decimal digit value. Applies only to characters that represent decimal digits in the decimal (base 10) system. A decimal digit can be one of ten digits, from zero through nine. These characters are members of the <xref:System.Globalization.UnicodeCategory.DecimalDigitNumber?displayProperty=nameWithType> category.

In addition, the <xref:System.Globalization.CharUnicodeInfo> class is used internally by a number of other .NET types and methods that rely on character classification. These include:

- The <xref:System.Globalization.StringInfo> class, which works with textual elements instead of single characters in a string.

- The overloads of the <xref:System.Char.GetUnicodeCategory*?displayProperty=nameWithType> method, which determine the category to which a character or surrogate pair belongs.

- The [character classes](/dotnet/standard/base-types/character-classes-in-regular-expressions) recognized by <xref:System.Text.RegularExpressions.Regex>, .NET's regular expression engine.

When using this class in your applications, keep in mind the following programming considerations for using the <xref:System.Char> type. The type can be difficult to use, and strings are generally preferable for representing linguistic content.

- A <xref:System.Char> object does not always correspond to a single character. Although the <xref:System.Char> type represents a single 16-bit value, some characters (such as grapheme clusters and surrogate pairs) consist of two or more UTF-16 code units. For more information, see "Char Objects and Unicode Characters" in the <xref:System.String> class.

- The notion of a "character" is also flexible. A character is often thought of as a glyph, but many glyphs require multiple code points. For example, ä can be represented either by two code points ("a" plus U+0308, which is the combining diaeresis), or by a single code point ("ä" or U+00A4). Some languages have many letters, characters, and glyphs that require multiple code points, which can cause confusion in linguistic content representation. For example, there is a ΰ (U+03B0, Greek small letter upsilon with dialytika and tonos), but there is no equivalent capital letter. Uppercasing such a value simply retrieves the original value.

## Examples
Expand All @@ -105,19 +99,7 @@ When using this class in your applications, keep in mind the following programmi
]]></format>
</remarks>
<block subset="none" type="usage">
<para>Recognized characters and the specific categories to which they belong are defined by the Unicode standard and can change from one version of the Unicode Standard to another. Categorization of characters in a particular version of .NET Framework is based on a single version of the Unicode Standard, regardless of the underlying operating system on which .NET Framework is running. The following table lists versions of .NET Framework since .NET Framework 4 and the versions of the Unicode Standard used to classify characters.

| .NET Framework version | Unicode Standard version |
| - | - |
| .NET Framework 4 | <see href="https://www.unicode.org/versions/Unicode5.0.0/">5.0.0</see> |
| .NET Framework 4.5 | <see href="https://www.unicode.org/versions/Unicode5.0.0/">5.0.0</see> |
| .NET Framework 4.5.1 | <see href="https://www.unicode.org/versions/Unicode5.0.0/">5.0.0</see> |
| .NET Framework 4.5.2 | <see href="https://www.unicode.org/versions/Unicode5.0.0/">5.0.0</see> |
| .NET Framework 4.6 | <see href="https://www.unicode.org/versions/Unicode6.3.0/">6.3.0</see> |
| .NET Framework 4.6.1 | <see href="https://www.unicode.org/versions/Unicode6.3.0/">6.3.0</see> |
| .NET Framework 4.6.2 | <see href="https://www.unicode.org/versions/Unicode8.0.0/">8.0.0</see> |

Each version of the Unicode standard includes information on changes to the Unicode character database since the previous version. The Unicode character database is used by the <see cref="T:System.Globalization.CharUnicodeInfo" /> class for categorizing characters.</para>
<para>Recognized characters and the specific categories to which they belong are defined by the Unicode standard and can change from one version of the Unicode Standard to another. Categorization of characters in a particular version of .NET is based on a single version of the Unicode Standard, regardless of the underlying operating system on which .NET is running. Each version of the Unicode standard includes information on changes to the Unicode character database since the previous version. The Unicode character database is used by the <see cref="T:System.Globalization.CharUnicodeInfo" /> class for categorizing characters.</para>
</block>
<altmember cref="T:System.Globalization.UnicodeCategory" />
<altmember cref="N:System.Text" />
Expand Down
2 changes: 1 addition & 1 deletion xml/System.Globalization/ChineseLunisolarCalendar.xml
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@
The <xref:System.Globalization.ChineseLunisolarCalendar> class is derived from the <xref:System.Globalization.EastAsianLunisolarCalendar> class, which represents the lunisolar calendar. The <xref:System.Globalization.EastAsianLunisolarCalendar> class supports the sexagenary year cycle (which repeats every 60 years) in addition to solar years and lunar months. Each solar year in the calendar is associated with a Sexagenary Year, a Celestial Stem, and a Terrestrial Branch, and these calendars can have leap months after any month of the year. The <xref:System.Globalization.ChineseLunisolarCalendar> class calculates years based on solar calculations, and months and days based on lunar calculations.

> [!NOTE]
> For information about using the <xref:System.Globalization.ChineseLunisolarCalendar> class and the other calendar classes in the .NET Framework, see [Working with Calendars](/dotnet/standard/datetime/working-with-calendars).
> For information about using the <xref:System.Globalization.ChineseLunisolarCalendar> class and the other calendar classes in .NET, see [Working with Calendars](/dotnet/standard/datetime/working-with-calendars).

A leap month can occur after any month in a year. For example, the <xref:System.Globalization.EastAsianLunisolarCalendar.GetMonth*> method returns a number between 1 and 13 that indicates the month associated with a specified date. If there is a leap month between the eighth and ninth months of the year, the <xref:System.Globalization.EastAsianLunisolarCalendar.GetMonth*> method returns 8 for the eighth month, 9 for the leap eighth month, and 10 for the ninth month.

Expand Down
28 changes: 8 additions & 20 deletions xml/System.Globalization/CompareInfo.xml
Original file line number Diff line number Diff line change
Expand Up @@ -1337,11 +1337,11 @@
The behavior of this overload is dependent on its implementation, which might change from one version of the common language runtime to another, or from one .NET implementation to another.

> [!IMPORTANT]
> If two character spans are equal, this overload returns identical values. However, there is not a unique hash code value for each unique character span value. Different character spans can return the same hash code.
> If two character spans are equal, this overload returns identical values. However, there is not a unique hash code value for each unique character span value. Different character spans can return the same hash code.
>
> The hash code itself is not guaranteed to be stable. Hash codes for identical character spans can differ across versions of the .NET implementations and across platforms (such as 32-bit and 64-bit) for a single version of .NET.
> The hash code itself is not guaranteed to be stable. Hash codes for identical character spans can differ across versions of the .NET implementations and across platforms (such as 32-bit and 64-bit) for a single version of .NET.
>
> As a result, hash codes should never be used outside of the application domain in which they were created, they should never be used as key fields in a collection, and they should never be persisted.
> As a result, hash codes should not be treated as unique identifiers, they should not be persisted, and they should not be used outside the current process.

]]></format>
</remarks>
Expand Down Expand Up @@ -1402,14 +1402,12 @@
<format type="text/markdown"><![CDATA[

## Remarks
The behavior of <xref:System.Globalization.CompareInfo.GetHashCode*> is dependent on its implementation, which might change from one version of the common language runtime to another, or from one .NET Framework platform to another.
The behavior of <xref:System.Globalization.CompareInfo.GetHashCode*> is dependent on its implementation, which might change from one version of the common language runtime to another, or from one platform to another.

> [!IMPORTANT]
> If two string objects are equal, the <xref:System.Globalization.CompareInfo.GetHashCode*> method returns identical values. However, there is not a unique hash code value for each unique string value. Different strings can return the same hash code.
> If two string objects are equal, the <xref:System.Globalization.CompareInfo.GetHashCode*> method returns identical values. However, there is not a unique hash code value for each unique string value. Different strings can return the same hash code.
>
> The hash code itself is not guaranteed to be stable. Hash codes for identical strings can differ across versions of the .NET Framework and across platforms (such as 32-bit and 64-bit) for a single version of the .NET Framework. In some cases, they can even differ by application domain.
>
> As a result, hash codes should never be used outside of the application domain in which they were created, they should never be used as key fields in a collection, and they should never be persisted.
> The hash code itself is not guaranteed to be stable. Hash codes for identical strings can differ across versions of .NET and across platforms (such as 32-bit and 64-bit) for a single version of .NET. Hash codes shouldn't be treated as unique identifiers, persisted, or used outside the current process.

]]></format>
</remarks>
Expand Down Expand Up @@ -5306,14 +5304,10 @@ This method has greater overhead than other <xref:System.Globalization.CompareIn
<remarks>
<format type="text/markdown"><![CDATA[

## Remarks
This method overrides the <xref:System.Object.ToString*?displayProperty=nameWithType> method. It returns a string that consists of the class name and the value of the instance <xref:System.Globalization.CompareInfo.Name> property, separated by a hyphen.
This method overrides the <xref:System.Object.ToString*?displayProperty=nameWithType> method. It returns a string that consists of the class name followed by a space, a hyphen, a space, and the value of the <see cref="P:System.Globalization.CompareInfo.Name" /> property.

]]></format>
</remarks>
<block subset="none" type="usage">
<para>Staring with the .NET Framework 4, the <see cref="M:System.Globalization.CompareInfo.ToString" /> method returns the class name followed by a space, a hyphen, a space, and the value of the <see cref="P:System.Globalization.CompareInfo.Name" /> property. For example, for a <see cref="T:System.Globalization.CompareInfo" /> object that represents the en-US culture, the <see cref="M:System.Globalization.CompareInfo.ToString" /> method returns "CompareInfo - en-US". In previous versions of the .NET Framework, it returns the class name followed by a space, a hyphen, a space, and the value of the <see cref="P:System.Globalization.CompareInfo.LCID" /> property. For example, for a <see cref="T:System.Globalization.CompareInfo" /> object that represents the en-US culture, the <see cref="M:System.Globalization.CompareInfo.ToString" /> method returns "CompareInfo - 1033".</para>
</block>
<altmember cref="M:System.Object.ToString" />
</Docs>
</Member>
Expand Down Expand Up @@ -5361,13 +5355,7 @@ This method has greater overhead than other <xref:System.Globalization.CompareIn
<format type="text/markdown"><![CDATA[

## Remarks
The weight of individual characters, and therefore the way in which particular strings are compared or ordered, depends on the version of the Unicode specification that a particular version of the .NET Framework implements. In the .NET Framework 4.5, this also depends on the host operating system, as the following table shows. Note that this list of supported Unicode versions applies to character comparison and sorting only; it does not apply to classification of Unicode characters by category.

|.NET Framework version|Operating system|Unicode version|
|----------------------------|----------------------|---------------------|
|.NET Framework 4|All operating systems|Unicode 5.0|
|.NET Framework 4.5 and later versions|Windows 7|Unicode 5.0|
|.NET Framework 4.5 and later versions|Windows 8 and later Windows operating system versions|Unicode 6.3|
The weight of individual characters, and therefore the way in which particular strings are compared or ordered, depends on the version of the Unicode specification that a particular version of .NET implements and the host operating system.

The <xref:System.Globalization.SortVersion> object returned by the <xref:System.Globalization.CompareInfo.Version> property doesn't identify the precise Unicode version used to compare strings. It is useful only when comparing two <xref:System.Globalization.SortVersion> objects to determine whether they use the same Unicode version and culture to compare strings. For more information and an example, see the <xref:System.Globalization.SortVersion> reference page.

Expand Down
Loading
Loading