We Keep Coding

Where System.Threading.Thread.CurrentThread.CurrentCulture is set

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).

DateTime displaying differently on Web server and local machine for same code (WebFroms)

I'm currently seeing a small discrepancy between an ASP.NET WebForms application on my local machine and on a server that I'm deploying to.
I am retrieving a date from a database (the actual db is the same in both cases). The date is the 1st of January 1900.
In my local machine this is displayed inside a text box as "01/01/1900"
However on the server it is displayed as "1/1/1900"
the code for assigning the date to the control is:
txtEffectiveDate.Text = ((DateTime)temp.Rows[0]["effective_date"]).ToShortDateString();
where temp is a DataTable representing the output of a stored procedure.
I have built the solution and transferred the relevant .dll file onto the server so it should the same code in both cases. I have also copied over the relevant .aspx page just to be sure but again that doesnt' make a difference.
Is there some kind of setting on the server that I need to tweak so that it shows the dates the same was as my local machine

ToShortDateString formats your date according to the pattern defined by the DateTimeFormatInfo.ShortDatePattern and its default value is controlled by the voice International settings in control panel.
Probably on your work machine is set as dd/MM/yyyy while on your server is d/M/yyyy
If you want to keep your working machine your could change to
txtEffectiveDate.Text = ((DateTime)temp.Rows[0]["effective_date"]).ToString("dd/MM/yyyy");
Or, just to follow the formal route, (see the MSDN examples in ToShortDateString)
CultureInfo originalCulture = new CultureInfo(CultureInfo.CurrentCulture.Name);
originalCulture.DateTimeFormat.ShortDatePattern = "d/M/yyyy";
txtEffectiveDate.Text = ((DateTime)temp.Rows[0]["effective_date"])
.ToString(originalCulture.DateTimeFormat.ShortDatePattern));

System Locale in .NET

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.

Current Culture and OS date configuration

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.

Where is the system locale/culture set for .Net

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.