Develop Reference

How to refesh short time string (C# DateTime.Now)?

I'm making a Notepad program with Windows Form and having a problem with the Date/Time feature:
My system time and date format (short) are hh:mm tt M/d/yyyy. When I press F5 (Date/Time feature) in Notepad, it add a time string with format like above. Then I change the system time and date format to HH:mm dd-MMM-YY and press F5 again in Notepad, it add another time string with the format I've changed.
But with my Notepad project (I use DateTime.Now.ToShortTimeString() and DateTime.Now.ToShortDateString() to do this feature), I have to start the program again if I want the format to take effect in my program, otherwise it will use the first format no matter how many times I press F5.
So I want to ask if there is a way to fix this.
I'm using VS 2013.

Very good question. The date is formatted according to current user culture information, but the information is cached by .NET. What you need to do is force .NET to clear the cache by calling CultureInfo.ClearCachedData method beforehand.
More information here: https://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo.clearcacheddata(v=vs.80).aspx
Please also note, that clearing the cache every time a user wants to insert Date & Time is somehow missing the point of caching (OK, I am exaggerating a little bit). What you can do is only clear the cache, when the system tells you that its configuration has changed. You do this by listening to SystemEvents.UserPreferenceChanged event. More information in answer here: How to receive event when user changes system's culture

See SystemEvents class, UserPreferenceChang* events.

CultureInfo("fr-BE") different on Windows 8.1 than before

I set the culture for an .NET web app in order to use specific format for numbers, currency and date:
System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("fr-BE");
On an Windows 2008 server machine with IIS 7 I get "d/m/yy" as short date format (what I want).
On my (new) Windows 8.1 pro machine (developer and test) I get "d-m-yy" format for the same CultureInfo..."dash" instead of "slash" separator.
I've checked also in Control Panel -> Region and the settings for French(Belgium) are as mentioned above, different in W2k8 server than in W8.1pro...
The .NET version is 4, which is ok. Invariant culture doesn't help, as far as I need specific culture to display in the UI and the problem was there. It is true, changes came with Windows 8... Finally I used to override some settings for the Thread culture, like the Date Separator:
DateTimeFormatInfo dtfi = Thread.CurrentThread.CurrentCulture.DateTimeFormat; if (dtfi.DateSeparator != "/") dtfi.DateSeparator = "/";
This ensure that slash will be the date separator all the time in the current thread.
Thank you.
Does anybody knows about it? Belgium changed national standards? Or, Microsoft did for them? Any idea?
Thanks.

Thanks for the answers. .NET version is 4, which is ok. Invariant culture doesn't help, as far as I need specific culture to display in the UI and the problem was there. It is true, changes came with Windows 8...
Finally I used to override some settings for the Thread culture, like the Date Separator:
DateTimeFormatInfo dtfi = Thread.CurrentThread.CurrentCulture.DateTimeFormat;
if (dtfi.DateSeparator != "/") dtfi.DateSeparator = "/";
This ensure that slash will be the date separator all the time in the current thread.
Thank you.

I was looking at similar issue for CultureInfo 'en-NZ', as it been changed for the same culture setting in different Windows version, and cause my web service saved different strings for the same CultureInfo, and it turns out it is provided by Windows since .Net Framework 4, and was a combination of Windows and .Net before that.
Lucky for me, I can make use of Invariant culture, which was recommended by Microsoft to make sure the string I saved into Database not going to be changed because of Windows or future .Net Framework update. The thing is, for my case it was the AM\PMDesignator changed from a.m.\p.m. to AM\PM, and the Invariant culture will make sure it saves to AM\PM I assume it will not change in the future, but if I want it save to a.m.\p.m. as it was for older version of Windows, Invariant culture wouldn't be able to do that, I will probably need define my own custom culture or overwrite the current culture as you did.
See the other question about Microsoft specified that CultureInof are subject to change without notice

.ToShortDateString returning different cultural format than expected

Here's a weird one for you.
We've got a c# interface that's been running since the beginning of the year without problem on a windows XP (32bit) PC. We've just upgraded the PC to windows 7 (64bit) with apps installed by SCCM.
With the latest run the dates in the text area have started appearing in US format (5/2/2014) instead of UK format (02/05/2014).
The code that is being used is:
string Lines = FromFormat.Text + " from " + FromFormat.Charge_From.ToShortDateString() + " to " + FromFormat.Charge_To.ToShortDateString() +".";
Where FromFormat is an object with the source data, Charge_From & Charge_To are DataTime variables.
We've checked the PC's regional settings and created a little test app to display the pc's settings from .Net both of these are set as UK formats
Code for test app:
label1.Text = DateTime.Now.ToString();
label2.Text = DateTime.Now.ToString("dd MMM yyyy");
label3.Text = DateTime.Now.ToShortDateString();
label4.Text = Thread.CurrentThread.CurrentCulture.EnglishName;
I know that I can replace the ToShortDateString() with a ToString("dd/MM/yyyy") to force the correct format but my question is why is this happening?
Is it something to do with the windows 7 upgrade? or the SCCM?
Thanks in advance

ToShortDateString method uses ShortDatePattern property which is identical of "d" standard date and time format of your CurrentCulture.
en-GB culture's ShortDatePattern property is dd/MM/yyyy.
But en-US culture's ShortDatePattern property is M/d/yyyy.
That's why you can't always replace with ToShortDateString and ToString("dd/MM/yyyy"). They are not always the same. And "/" Custom Format Specifier has a special meaning as replace me with the current culture or specified culture's date separator.
I suspect your regional settings changed on your upgrade process and that's why ToShortDateString method generates different results.
But since you didn't tell us your CurrentCulture, we never know what the real problem is..

After much testing and scratching of heads we think we've found an answer to this.
During the testing we noticed that PC’s that had had the interface installed via SCCM (windows 7 only) were producing the US date formatted text but those that were via Click Once directly (predominantly XP) were producing UK date formatted text.
Further testing confirmed that if we installed a Windows 7 PC via Click Once we got UK date formatted text.
Following a lot of confusion, we noticed that when SCCM installed the interface it was installing the RTM version of the Report Viewer but when Click Once was installing the interface the SP1 version of the Report Viewer was installed.
We altered the SCCM to install Report Viewer SP1 and tested a new SCCM installed version of the interface and got UK dates.
Why the version of Report Viewer would affect the culture settings of a PC or how ToShortDateString() works, we have no idea but this appears to be what the issue is.

Convert.ToDouble("4089.90") outputs 40.899,00 why?

I am developing a software that uses number precision, but I have this problem, it happens that when I take a string to convert to double it outputs me with a different culture.
For example I use
Convert.ToDouble("4089.90"); // it outputs 40.899,00
Is strange cause in my computer it works OK but on the client's PC (with the same culture in regional settings) shows me the latter output. I know I can fix it using
Convert.ToDouble("4089.90", System.Globalization.CultureInfo.InvariantCulture);
But there is a lot of code in the program using "Convert.ToDouble" and I wouldn't like to change all of it, on the other hand I want to understand why this happens.

You can set the culture for your thread with:
Thread.CurrentThread.CurrentCulture =
System.Globalization.CultureInfo.InvariantCulture;

You don't say where you are based, but the output is consistent with the current culture being one that has "." as the thousands separator and a decimal comma rather than a decimal point.
However, you state that the culture is the same - which contradicts this. Have you or the client changed (or customised) the "Standards and formats" on the Regional and Language Options? If the setting has been customised it will still read as "English (United Kingdom)" (or where ever) but will produce different results to the default.

I know neither c# nor asp.net, but I think the problem is this: You are performing the operation in a culture where the dot . is the thousands separator and not the decimal separator. The very output you quote is the proof: 40.899,00.
What culture/locale are you working in?

Culture could be based on where the ASP.Net application is running, and not the client PC that is running the browser. While their desktop PC might have similar culture settings, the server may differ.

It is your computer that is not giving the correct answer, not theirs. Your culture states that "4089.90" is the same as 4089900, since the dot (.) is used for separating thousands (and thus there should be three numbers after the dot).
It appears you want to use the dot as a decimal-separator, contrary to your culture settings; so you have to use System.Globalization.CultureInfo.InvariantCulture in your program. Sorry.

Actually is very rare this behaviour cause all the machines have the same culture settings, however I think that the best solution would be to modify the web.config like this:
configuration>
<system.web>
<globalization culture = "es-HN" />
</system.web>
</configuration
And apply the settings for the entire application.
Thanx everyone for your assistance.

How can I change a Windows user's regional settings/date format?

I use a VB6/COM+ application which outputs date/time values based on the short date settings in the Control Panel, Regional Settings, for the user that runs it. The program that then parses that output has a configurable setting for the date format it expects, and presents in the UI.
e.g. If the regional setting for the user is set to mm/dd/yyyy, and it outputs 06/18/2009, the application expecting "18/06/2009" fails with "String was not recognized as a valid DateTime".
As we usually run this application as a service account, which we have not logged in as interactively to create a profile, we generally set the correct date format and then tick the "Apply all settings to the current user account and the default user profile" option.
I would like to be make the C# configuration utility I have written for this mess to be able to set the date format programmatically for a given user.
Edit
I would like nothing more than to change the code, but do not have the ability to do so at this time.
I also know that what I am asking is a bad thing to do. With regards to "it should be the user's choice" - I am that user, as I create it explicitly for the task; I just want to set the date format by a scripted method, rather than having to do the clicking myself.

This is specifically discouraged by Microsoft. Any solution you may come up with will be a filthy hack that will probably stop working soon.
Think of it this way: who are you to decide those settings? Don't you think that's the user's decision?
Back on topic: find an unambiguous format for the applications to communicate in, such as YYYYMMDD. The application that displays can then simply respect the actual user settings, as it should.
But, since you can't change it, just poke into the registry:
Current user:
HKEY_CURRENT_USER\Control Panel\International
Specific user:
HKEY_USERS\(user SID)\Control Panel\International
Default user:
HKEY_USERS\.DEFAULT\Control Panel\International
sShortDate is probably the value you want to change.

If you are going to modify the profile to suit your needs, why not just ignore the profile settings and hardcode the format you want in your app?

code:
Imports System.Threading
Thread.CurrentThread.CurrentCulture = New CultureInfo("en-US", False)
Microsoft.Win32.Registry.SetValue("HKEY_CURRENT_USER\Control Panel\International", "sShortDate", "M/d/yyyy")

While persistently changing a user's culture (regional settings) is to be done cautiously, there are legitimate use cases.
On Windows 8 and Windows Server 2012 and above, Windows PowerShell comes with the
Set-Culture cmdlet, which is the programmatic equivalent of choosing a different region via Control Panel (intl.cpl).
For instance, Set-Culture fr-CA is the equivalent of interactively choosing region French (Canada) for the current user.
Caveat: Mixed cultures such as en-DE (sic) appear not to work as of Windows PowerShell v5.1 - see this answer of mine.
While it won't be fast, it is possible to call PowerShell commands from C#.