Asked by:
How dot net code treated in different environments like Visual Studio, Visual Studio Debug, Build, Runtime?

Question
-
User-777350147 posted
I have a couple of doubts regarding how numbers, date formats other culture-specific things treated in dot net.
For example please consider these below two statements written in English culture.
Number and string representing date are hardcoded to specific English culture and checking on culture change will these be converted to a specific culture.
double double_number = 10.25; // Datetime format in English culture dddd, MMMM d, yyyy. // Equilant turkey value is '30 Mayıs 2020 Cumartesi' with format 'd MMMM yyyy dddd'. string date_string = "Saturday, May 30, 2020"; // Converts correctly. string double_number_string = double_number.ToString(); // No format specified. Converts correctly. DateTime.TryParse(date_string, out DateTime result1); // Change culture to Turkey where both number and date formats are different. Thread.CurrentThread.CurrentUICulture = new CultureInfo("tr-TR"); Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("tr-TR"); // Converts correctly. string double_number_string1 = double_number.ToString(); // No format specified. Converts correctly. DateTime.TryParse(date_string, out DateTime result2);
I have a Visual Studio installed in the English version.
Assumption 1: I think Visual Studio will expect the code to be written in English culture.
Assumption 2: After a change in a culture still dot net is able to convert correctly. This will be possible only when the build happens to
Invariant Language (Invariant Country)
culture. This means the conversion of these numbers and strings toInvariant Language (Invariant Country)
culture should have happened on the build.Assumption 3: If Assumption 2 is wrong then build should have culture-specific information with it and the dot net will convert these numbers and strings and provide when we access them. I feel this would be the wrong assumption and Assumption 2 is correct.
Assumption 4: Number conversion to specific culture is understandable because the type is an integer. But how dot net is treating this date string and converting to correct date in a different culture through the date-time format of turkey culture is different. I am expecting it to throw an error. This makes me not sure if Assumption 2 is correct or assumption 3 is correct. But I don't think strings are processed and converted to
Invariant Language (Invariant Country)
. So, not sure how is date is converted correctly here.Assumption 5: Inspect of number is always shown in
Invariant Language (Invariant Country)
or probably in English culture because Visual Studio is in English culture. I think inspect will evaluate from the build, so does this mean inspect is converting to Visual Studio culture.Is any of my assumptions correct?
With regards,
Nithin B.
Sunday, May 31, 2020 7:19 AM
All replies
-
User475983607 posted
I have a Visual Studio installed in the English version.
Assumption 1: I think Visual Studio will expect the code to be written in English culture.
No. You set the default culture when you setup your computer.
Assumption 2: After a change in a culture still dot net is able to convert correctly. This will be possible only when the build happens toInvariant Language (Invariant Country)
culture. This means the conversion of these numbers and strings toInvariant Language (Invariant Country)
culture should have happened on the build.I do not understand your question. The reference documentation covers the InvariantCulture property; https://docs.microsoft.com/en-us/dotnet/api/system.globalization.cultureinfo.invariantculture?view=netcore-3.1
The invariant culture is culture-insensitive; it is associated with the English language but not with any country/region.
Assumption 4: Number conversion to specific culture is understandable because the type is an integer. But how dot net is treating this date string and converting to correct date in a different culture through the date-time format of turkey culture is different. I am expecting it to throw an error. This makes me not sure if Assumption 2 is correct or assumption 3 is correct. But I don't think strings are processed and converted toInvariant Language (Invariant Country)
. So, not sure how is date is converted correctly here.See the reference documentation rather than guessing;
https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-date-and-time-format-strings
https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings
Assumption 5: Inspect of number is always shown inInvariant Language (Invariant Country)
or probably in English culture because Visual Studio is in English culture. I think inspect will evaluate from the build, so does this mean inspect is converting to Visual Studio culture.No. InvariantCulture is a setting in the C# language that you as a developer get to use if it fits your requirements. From the docs...
Unlike culture-sensitive data, which is subject to change by user customization or by updates to the .NET Framework or the operating system, invariant culture data is stable over time and across installed cultures and cannot be customized by users. This makes the invariant culture particularly useful for operations that require culture-independent results, such as formatting and parsing operations that persist formatted data, or sorting and ordering operations that require that data be displayed in a fixed order regardless of culture.
Sunday, May 31, 2020 12:16 PM -
User-777350147 posted
@mgebhard
Thanks for the response, I think I did a simple test and got confused. The below test with different number clears my doubt.
I was thinking the number 12.345,68 will be converted to 12,345.68 when code is built(Into Invariant Language (Invariant Country)) which is the wrong assumption.
I thought so because in the above test, the number 10.25 was valid for both cultures and I didn't realize that. If I had used the other number I can't build only.
const string number_string_de_1 = "12.345,68"; const string number_string_de_2 = "12.345"; string date_string_eng = "Saturday, May 30, 2020"; string date_string_de = "Samstag, Mai 30, 2020"; Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US"); decimal.TryParse(number_string_de_1, out decimal number_eng); // Will not convert correctly because not valid for culture. decimal.TryParse(number_string_de_2, out decimal number_end_1); // Will convert correctly because valid for culture. DateTime.TryParse(date_string_eng, out DateTime date_eng); // Will convert correctly because valid for culture. DateTime.TryParse(date_string_de, out DateTime date_eng_1); // Will not convert correctly because not valid for culture. Thread.CurrentThread.CurrentCulture = new CultureInfo("de-DE"); decimal.TryParse(number_string_de_1, out decimal number_de); // Will convert correctly because valid for culture. decimal.TryParse(number_string_de_2, out decimal number_de_1); // Will convert correctly because valid for culture. DateTime.TryParse(date_string_eng, out DateTime date_de); // Will convert correctly. How?? Because it is valid for neutral culture? DateTime.TryParse(date_string_de, out DateTime date_de_1); // Will convert correctly because valid for culture.
But I still don't understand how is this date string(The one that is in English) converted to the correct date in both cultures though it's not valid for de-DE culture.
Is it because of the DateTime.TryParse also check if it of Invariant Language (Invariant Country) too?
Visual studio inspects will always show in English(Numbers) maybe because inspect will always convert to Invariant Language (Invariant Country). Is this correct?
Sunday, May 31, 2020 3:30 PM