.net - Is this c# code enough to handle globalization? -

my c# winforms program used in following countries

united kingdom  : date format day-month-year , currency separator '.' united states   : date format month-day-year , currency separator '.' denmark         : date format day-month-year , currency separator ',' 

i want make program run irrespective of regional settings on users computer. main concern handling date format , currency fields (language translation not problem because program show english text)

to have decided dates in database saved yyyy-mm-dd format , decimal fields saved . separator.
created database danish_norwegian_ci_as collation . assuming data saved in above datetime format & decimal format without me requiring special.

i have put following code in program

var cult = new cultureinfo("en-gb"); thread.currentthread.currentculture = cult; thread.currentthread.currentuiculture = cult;  cultureinfo.defaultthreadcurrentculture = cult; cultureinfo.defaultthreadcurrentuiculture = cult; 

please me telling experience if above code enough make program safe

culture applies only in following 2 scenarios:

• converting string representation of value native format, called "parsing".

• converting native format of value string representation, called "formatting".

when store datetime or decimal or other type database, stored in native format. in sql database, compact binary value never work directly.

consider following sql:

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

in first line, declare variable of type datetime. it's not string, it's specific data type takes 8 bytes of memory or disk.

in second line, assign string value variable. sql parses string, converting datetime can stored in @dt variable. actual value stored has hexadecimal representation of 0x0000a41400cf5940.

when did parsing, current culture environment code running applied. because in usa, interpreted date january 2nd. if in europe, interpret date february 1st (changing internal value 0x0000a43200cf5940).

using dates in yyyy-mm-dd format avoid misinterpretation, not mean actual value stored string in format. it's format unambiguous, parsed same way regardless of culture.

in third line of code above, select variable include in result set. though selecting in native form without conversion, see in string representation. if running query in tool such sql server management studio, output window format native values strings can read them. when doing so, current culture again applied. sql's default show dates in yyyy-mm-dd format, rather culture-specific format. other values, such decimals, use current culture's separator.

if instead of running in ssms retrieved results through own code in sqldatareader (for example), formatting never occurs. reader maps sql's binary native value directly appropriate .net native type, using the mappings shown here. sql datetime gets natively mapped .net datetime.

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

now quite often, see doing silly things this:

datetime dt = convert.todatetime(reader["dt"].tostring()); 

this wasteful because value already datetime, , code use current culture format string, use again parse string. that's lot of string manipulation no reason whatsoever.

ultimately, in .net code, end using datetime value , converting string somewhere output. when do, that's when apply current culture.

likewise, when receive input string user (such when filling out form), parse value datetime using current culture again.

native data types are not strings - , not affected culture.

notes:

• if want see hexadecimal representation of native binary form of sql data type, can use like: select convert(varbinary, @dt)

• be aware of whatever native format anywhere working. if you're writing http stream, text file, or document database, etc., string representation indeed matter, because string is native format in scenarios.

and prove applies more dates, consider:

select 123, 123.45, convert(varbinary, 123), convert(varbinary, 123.45)  --results:    123    123.45    0x0000007b    0x0502000139300000