Where is System.Threading.Thread.CurrentThread.CurrentCulture set? I have a US customer (and I am in US); the debugging code shows the value equals "en-GB". And therefore dates are shown in British format ('DD/MM/YYYY'). Where is this set, in which file?
You can force current CultureInfos by CultureInfo.CurrentUICulture and CultureInfo.CurrentCulture.
The first one effects to text based things such like datetime etc. The second one effects to numbers such like floating points. Setting both to same CultureInfo is basic implement.
Note that, this will work fine if you don't consider multi-languages. Or you need to add language selecting menus.
Generally, CultureInfo comes from the OS (presuming it's not explicitly overridden in code); in case of a web application, CultureInfo typically comes from the client OS, via HTTP's Accept-Language header (you can likely monitor this with tools like Fiddler, etc).
In your case, if it's possible to ask the client to check their system setting - on Windows 10, the PowerShell command Get-Culture will return the current culture set in the OS, for instance - you might be able to determine the source of the problem.
Furthermore, it is possible to set a different culture for the current user (no Admin required, I believe), using the PowerShell Set-Culture -CultureInfo en-US command, where en-US is the desired culture (no pun intended). There is also a way to reset it for the entire machine, with the PowerShell Set-WinSystemLocale -SystemLocale en-US command (Admin rights and a reboot are required).
Related
I have set the system locale to Chinese (Simplified PRC) via
ControlPanel >> Region and Language >> Administrative >> Change System locale
I then restarted my computer and run my .NET 4.0 application.
Running
Thread.CurrentThread.CurrentCulture.Name
Returns
en-GB
Why?
MSDN says that
Information, such as the default culture and format patterns, is
cached the first time it is requested. That information can change
during the life of the AppDomain, for example, when the user modifies
the regional and language options portion of Control Panel. However,
the CultureInfo class does not automatically detect changes in the
system settings.
call this first
Thread.CurrentThread.CurrentCulture.ClearCachedData();
Looks like the place to see the system locale is System.Text.Encoding.Default
PS: The "...Change system locale" affects the ANSI codepage used for "non-Unicode" applications (the *A() calls from Win32 API). In most cases .NET applications do not need to care about it because they use Unicode strings and Unicode API. But I have to interact with non-unicode application, so I need to inquire the current system locale.
I have a very tricky question here. I've been benging my head on this issue for several hours with no success.
I am building an application to be deployed on numerous machines, with different cultures.
As a precautionary I decided to use the Culture class to help convert between string to dates.
I noticed that when I change my windows operation system date from :
10/07/2011 to 10-07-2011
The CurrentCulture doesn't get updated, I keep seeing the dates as 10/07/2011.
Why is that? Is there any workaround?
You need to change the Culture in the IIS environment (or better in Web.config) and not in the OS.
that way you'll Guarantee that all the machines will work on the same Culture.
try to add the following line to your web.config:
<globalization culture="he-IL" enableClientBasedCulture="false" uiCulture="he-IL" />
just change the he-IL to your proffered culture
It works correctly for me, but only after I restart my application. I assume the current culture is loaded at the start of the application and cached, so, for the change to take effect, you have to restart the application.
A long as the value can still be interpreted as a date, it will always be formatted to your CurrentCulture. This is by design.
You need to explicitly change CurrentCulture, so data shows (or is converted) to a new format. Look at CurrentCulture as how data is going to be displayed on your end.
I have a problem with a c# assembly (.net 2.0 written using Visual studio 2005) that is installed on a UK server and should use UK regional settings.
What my code does is to convert a date in the form dd/MM/yyyy into utc. i.e. yyyy-mm-dd. The problem arose with dates like 16/02/2010 where the component failed to convert the date and returned Error. After debugging I realised that, for a strange reason, the CultureInfo returned by System.CultureInfo is en-US.
I can programatically change those settings using:
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-GB", false);
and my code works fine.
However I don't want to do that all the time as my system should be UK. Not US.
So, how do I change the default culture for .Net framework to be by default en-GB instead of en-US ?
For information:
I have tried to update the machine.config file and specify culture=en-GB for the globalization section (it was set to neutral) but it doesn't work either [have done that for 1.1 and 2.0] but it's possible I have not changed it correctly.
I have verified my windows regional settings and they are definitely set-up to UK with dates as dd/MM/yyyy
I am running in a Virtual server and have verified my host system. It too is set to UK
Edit:
A bit of extra detail about the context. The assembly in question is being called via COM interop from a native C++ third party component that is running as a COM+ application.
The server is not configured correctly. Control Panel + Region and Language, Location tab. Changing this could be a bit tricky. The server may well have been mis-configured on purpose. Talk to the server administrator first before doing anything.
Your fallback plan is to use the DateTime.TryParse() method overload that takes the IFormatProvider argument. Pass CultureInfo.GetCultureInfo("en-gb").DateTimeFormat.
To set the UI culture and culture for all pages, add a globalization section to the Web.config file, and then set the uiculture and culture attributes, as shown in the following example:
<globalization uiCulture="en" culture="en-GB" />
Hmmm, according to the API Docs:
When a thread is started, its culture is initially determined by using GetUserDefaultLCID from the Windows API.
This method derives it's locale from the (as the name implies) User's Default Locale, which I assume is in the Control Panel. NOTE: This is NOT the same as the UI Locale.
thanks for your answers (andy posted the question on my behalf). It was indeed an issue with regional settings but neither with the user I was connected under, nor with the user the process was running under. That would have been too easy. It looks like that the default user was still en-US. I did reset by clicking the checkbox "Apply settings to the current user and default user..." in the advanced tab and rebooting the server. System.Globalization.CultureInfo now return {en-GB}. And a MyDate.ToString(yyyy-mm-dd) works fine whether the date is passed as dd/MM/yyyy or dd-MM-yyyy or yyyy-MM-dd without the need to parse.
However thanks you all very much for your suggestions (ParseExact, etc) that did indeed work. They ill be very helpful for other date formats that I was not able to handle in a nice way (yyyyMMdd).
Marc
I believe this is represented by System.Globalization.CultureInfo.InstalledUICulture, so if nothing else maybe you can copy that to the thread's current culture. I'm surprised that you found a case where the threads culture is different than the installed culture. Perhaps your code is running in a process that changed the culture?
It is possible the account running the code has different regional settings than the system default. Have you checked that?
You do not have to change the CurrentCulture to do the transformation. If you are certain that the date is in the form of "dd/MM/yyyy" you could use
DateTime dtTemp = DateTime.ParseExact(dateString, "dd/MM/yyyy", null) // in order not to have to specify a FormatProvider
and then use
dtTemp.ToString("yyyy-MM-dd")
This way you will not have a problem no matter what the CurrentCulture is. However, if you are not certain that the Date is of the form "dd/MM/yyyy" rather it is based on the CurrentCulture short date format, then you should use
DateTime dtTemp = DateTime(dateString, CurrentCulture.DateTimeFormat.ShortDatePattern, CurrentCulture.DateTimeFormat);
Assemblies in .net framework are culture neutral.
What code are you trying to convert the date?
If you are using Parse or TryParse, try providing the culture argument for it to understand the date.
I have a function that's designed to tell me which country my websites being run in (The website is run on a UK and Irish server). Basically I use:
RegionInfo.CurrentRegion.EnglishName;
To get this information. However when I run this function on the Irish server I still get "United Kingdom" returned. The web servers regioning in the control panel is set up as being Irish so I don't know where it's going wrong.
Any ideas? Thanks
RegionInfo.CurrentRegion uses CultureInfo.CurrentCulture as the basis for the region it returns. This in turn uses the CurrentCulture of the current thread. If a culture has not been set on the thread, it defaults to the "user default culture" - which it gets from the underlying OS.
As Henk says, this is determined by the Formats section in the regional control panel applet, not the location. If the formats section is set to Ireland, RegionInfo.CurrentRegion.EnglishName does output Ireland.
I've got a German VisualStudio 9.0. Working with doubles and doing quite some parsing, I came into trouble because of the decimal separator.
What I'm looking for is a way to either switch the whole IDE (and therefore all the projects created with it) to "en-gb" or do it project wide. I chose en-gb because of the lack of am's and pm's which I don't need.
I tried to set it by using Thread.CurrentThread.CurrentCulture, but this regards only the one thread. Then I found the Application wide setting, which seems to be not what I'm looking for when developing console applications.
Any idea? Thank you for reading.
The culture of the application defaults to the culture of the machine it's running on, not the machine it was developed on. The IDE is irrelevant here.
If you need to parse/format values using a specific culture, I suggest you do that explicitly - changing the current culture of all threads would be incorrect in almost all settings, IMO.