这个C＃代码足以应付全球化吗？

Question

My C# winforms program will be used in following countries

United Kingdom  : date format day-month-year , currency separator is '.'
United States   : date format month-day-year , currency separator is '.'
Denmark         : date format day-month-year , currency separator is ','

I want to make the program run properly irrespective of what regional settings are on users computer. My main concern is handling date format and currency fields (Language translation is not a problem because the program will only show English text)

To do this I have decided that all dates in the database will be saved with yyyy-mm-dd format and all decimal fields will be saved with . as separator.
I created the database with Danish_Norwegian_CI_AS collation . So I am assuming the data will be saved in the above datetime format & decimal format without me requiring to do anything special.

I have put the following code in my program

var cult = new CultureInfo("en-GB");
Thread.CurrentThread.CurrentCulture = cult;
Thread.CurrentThread.CurrentUICulture = cult;

CultureInfo.DefaultThreadCurrentCulture = cult;
CultureInfo.DefaultThreadCurrentUICulture = cult;

Please help me by telling from your experience if the above code is enough to make my program safe

Answer 1

Culture applies only in the following two scenarios:

• Converting a string representation of a value to a native format, which is called "parsing".

• Converting the native format of a value to a string representation, which is called "formatting".

When you store a datetime or a decimal or some other type into the database, it is stored in a native format. In a SQL database, this is usually some compact binary value that you will never work with directly.

Consider the following SQL:

declare @dt datetime
set @dt = '01/02/2015 12:34:56'
select @dt

In the first line, we declare a variable of type datetime . It's not a string, it's a specific data type that takes up 8 bytes of memory or disk.

In the second line, we assign a string value to the variable. SQL parses the string, converting it to a datetime so it can be stored in the @dt variable. The actual value stored has a hexadecimal representation of 0x0000A41400CF5940 .

When it did the parsing, the current culture for the environment where the code was running was applied. Because I am in the USA, it interpreted the date as January 2nd. If I was in Europe, it would interpret the date as February 1st (changing the internal value to 0x0000A43200CF5940 ).

Using dates in yyyy-mm-dd format will avoid misinterpretation, but that does not mean that the actual value is stored as a string in that format. It's just that the format is unambiguous, so it will be parsed the same way regardless of culture.

In the third line of code above, we select the variable to include it in a result set. Though we are selecting it in its native form without any conversion, we ultimately see it in a string representation. If you are running the query in a tool such as SQL Server Management Studio, the output window will format the native values to strings so you can read them. When doing so, the current culture is again applied. SQL's default is to show dates in yyyy-mm-dd format, rather than the culture-specific format. But other values, such as decimals, will use the current culture's separator.

If instead of running this in SSMS you actually retrieved the results through your own code in a SqlDataReader (for example), then formatting never occurs. The reader maps SQL's binary native value directly to the appropriate .NET native type, using the mappings shown here . A SQL datetime gets natively mapped to a .NET DateTime .

DateTime dt = (DateTime) reader["dt"];

Now quite often, you see someone doing silly things like this:

DateTime dt = Convert.ToDateTime(reader["dt"].ToString());

This is wasteful because the value is already a DateTime , and this code would use the current culture to format the string, then use it again to parse the string. That's a lot of string manipulation for no reason whatsoever.

Ultimately, in your .NET code, you will end up using that DateTime value and converting it to a string somewhere for output. When you do, that's when you apply the current culture.

Likewise, when you receive an input string from your user (such as when filling out a form), you parse the value to a DateTime using the current culture again.

Native data types are not strings - and are thus not affected by culture.

Notes:

• If you want to see the hexadecimal representation of the native binary form of any SQL data type, you can use something like: select convert(varbinary, @dt)

• Be aware of whatever the native format is for anywhere you are working. If you're writing to an http stream, a text file, or a document database, etc., the string representation does indeed matter, because a string is the native format in those scenarios.

And just to prove this applies to more than dates, consider:

select 123, 123.45, convert(varbinary, 123), convert(varbinary, 123.45)

--results:    123    123.45    0x0000007B    0x0502000139300000