|
Short Description
|
Misspelled culture day & month names were corrected. Culture data is unstable and should not be relied upon. |
Affected APIs
|
System.Globalization.CultureInfo; System.Globalization.DateTimeFormat; System.Globalization.DateTimeFormatInfo |
Severity
|
Medium |
Compat Switch Available
|
No |
|
Description
|
4 cultures had incorrect month names. ar-MA, nn-NO, kn-IN & div-MV. Those were corrected, but applications relying on the misspellings could be broken. Applications should specify their own formats when storing dates/times or other culture information and not rely on culture specific data. This goes for any culture data. Cultural preferences can change, goverment or business standards can change. With v2.0 people can override culture data with whatever they feel like. |
|
User Scenario
|
Use a culture to format dates/times in v1.1 and try to parse them in v2.0. |
|
Work Around
|
Build a custom culture with the incorrect spellings. |
|
|
Short Description
|
'U' format in DateTime.ToString() has different behavior for Japanese Calendar betweeen |
Affected APIs
|
DateTime.ToString() with "U" format for ja-JP culture. |
Severity
|
Medium |
Compat Switch Available
|
No |
|
Description
|
The 'U' format (Universal time in Gregorian format) is used to print DateTime using GregorianCalendar (Gregorian localized calanedar). However, if the current calendar setting from the OS is the Japanese Calendar for the ja-JP culture and it uses the Japanese Calendar specific format (such as "gg yy'?'MM'?'dd'?'"), V1.0/V1.1 used to format 'U' using Japanese calendar format, instead of the correct Gregorian localized format. This is fixed in V2.0 |
|
User Scenario
|
The user would like to print out the DateTime using "U" format (Universal Time using Gregorian localized format) and the current locale setting from OS is ja-JP, the current calendar is Japanese Calendar, and a Japanese calendar format is selected, such as "gg yy'?'MM'?'dd'?'") |
|
Work Around
|
If the user still needs the V1.0/V1.1 behavior, one can convert the DateTime instance into universal time and format the DateTime using the Long date format of the JapaneseCalendar. |
|
|
Short Description
|
the culture identifier ky-KZ was changed to ky-KG to match international conventions |
Affected APIs
|
Culture data, which shows up through APIs such as CultureInfo and ResourceManager.GetString. |
Severity
|
Low |
Compat Switch Available
|
No |
|
Description
|
The cultue Ky-KZ was wrong and we changed it ky-KG however anyone who wrote an app and set Thread culture to ky-KZ will be broken. Apps that worked in V1.x will now throw "Unhandled Exception: System.ArgumentException: Culture name 'ky-KZ' is not supported." KG is the official ISO tag for kyrgyzstan. There is no country whose official ISO tag is KZ. |
|
User Scenario
|
Using the official ISO tag for Kyrgyzstan will now work. Using the incorrect tag will no longer work. If someone had created resources, tagged them as ky-kz, then did a ResourceManager.GetString("resid", "ky-KZ"), we will fail when trying to create the CultureInfo for ky-KZ, and will also therefore fail to find the resources tagged ky-KZ |
|
Work Around
|
None |
|
|
Short Description
|
UnicodeDecoder throws when handling surrogate characters |
Affected APIs
|
UnicodeEncoding.Decoder.GetChars() |
Severity
|
Medium |
Compat Switch Available
|
No |
|
Description
|
When the Decoder for the UnicodeEncoding is asked to decode a high surrogate, V1.1 will return the high surrogate character (1 Unicode character) without considering the next two bytes to be a valid low surrogate or not. In V2.0, we now will only return the full surrogate pair (2 Unicode characters) after we see all 4 bytes are valid surrogate pair. If the caller try to decode the first 2 character, the state will be remembered, and the high surrogate will not be output. The complete surrogate pair will be only outputed when the decoder receives a valid low surrogate |
|
User Scenario
|
The caller gets Decoder for UnicodeEncoding, and decodes two bytes at a time by calling something like Decoder.GetChars(inputBytes, inputBytePos, 2, outputChars, outputCharPos) and expect a Unicode character will be always returned, so always increment currentCharPos by 1 in every call |
|
Work Around
|
The previous scenario totally ignore the returned value from first GetChar() calls, and assume that one Unicode character will be returned. This is wrong assumption because we are not supposed to return a partial high surrgate until a low surrogate is following. Version 1.1 has a bug on this. We change this behavior to be compatible with Unicode standard so that a invalid surrogate will not never be generated from our APIs. To work around, the proper usage is that the caller should use the returned value from GetChars() to update the outputCharPos correctly, instead of always incrementing by 1. |
|