tags:

views:

1758

answers:

3

Hi,

I have a situation where I save a string representation of dates/numbers etc in the DB, and since the application is run in multiple countries and sometimes with users in different countries using the same DB, I store the CurrentCulture.Name in the DB with the record so that when converting on the client side, it converts using the correct culture info. For example:

DateTime dt = Convert.ToDateTime(value, new CultureInfo(value.ClientCulture));

This works well, the question I have is, when calling new CultureInfo(value.ClientCulture), is it getting the CultureInfo from the .NET Framework or from Windows? I'm worried that if calling from Windows, if those languages arent installed, issues may arise. If calling from the .NET Framework itsself, then I see no issues.

Thanks

A: 

Judging from MSDN I'd assume the constructor will throw an ArgumentException, since the culture does not exist on the machine.

From a quick read over the CultureInfo class, it looks like a CultureInfo object is serialized to only a Name and UseUserOverride, meaning that any real information about the cultures are stored within Windows anyways and rely on the Name being correct.

Will Eddins
A: 

"I store the CurrentCulture.Name in the DB with the record so that when converting on the client side"

I don't think you should store the culture info with a date

If you want to remember an user's prefered way to display a date you could consider this,

however in most cases the format of a date (the way it is displayed) depends on the user's regional settings. (A user must be able to change them);

Just see what the user's regional settings are and you should be fine.

To answer your question:

The CultureInfo instance that is returned from the CultureInfo.CurrentCulture property is based on the locale the user selected in Windows® Regional Options (shown in Figure 1). This is called the "user locale" for programmers, and "language" for Standards and Formats in Windows XP and Windows Server™ 2003.

You shouldn't have to worry about the installed languages, because the language the user is using is always installed! (ditto selected regional settings)

See http://msdn.microsoft.com/en-us/magazine/cc163824.aspx

+2  A: 

The correct answer is: Do not store user-specific date time string in db!

Nowadays every db have datetime type, so you must convert string to datetime value using current user locale and put this value in db (instead of string).

If, in some strange case, db does not support datetime type, or maybe there is some other requirements (however I cannot invent even one), then you must convert date time into invariant datetime string, and put this string in db.

BTW, for speedup reason, you should use GetCultureInfo method instead of creating new CultureInfo instance:

DateTime dt = Convert.ToDateTime(value, CultureInfo.GetCultureInfo(value.ClientCulture));
arbiter