My .Net .exe is used to read a file and store information in sql DB.
On the dev system we had default setting and files in US locale and things were working fine.
I used the same .exe and deployed on to our Prod server where the default setting and files are in UK locale.
I have used the Datetime.Parse which should be parsing the date in the format of local system i.e for US MM/dd/yyyy and for UK dd/MM/yyyy.
But while parsing the date in UK format it gives an exception, Can someone help me out where am I doing wrong.
I also noticed something strange that when I changed the default setting of dev machine to UK and then compiled the .exe and deployed the same it worked.
Can you also let me know why did it worked.
you have to supply an iformatprovider (i.e. an instance of a System.Globalization.CultureInfo) to your DateTime.Parse() method. btw, i suggest using TryParse or if you exactly know how your datetime strings arrive, use TryParseExact as they are much faster.
The best solution is to specify the locale in the app.config, overriding the machine's.
Hard to say without more details, but maybe the application server and the sql server ran on another language setting than you expected. Even when you got the culture setting on the application server right, the date time formats on the sql server still are not as expected.
Related
I have a C# forms application. As a part of its functionality, it writes double values to a file in string format, some of which are double.Infinity.
There is another part of application that reads these values from file and converts them back to double.
When writing values part is performed on windows 7 and reading the same file is performed on Windows 10, then there is format exception while converting 'infinity'. It appears the symbol used by the default (us-en) culture changed between Windows 8 and 10.
There are many instances of Convert.ToDouble() in application and handling each of these instances through try-catch or by using double.tryParse() isn't a feasible solution as it will require changes in many projects.
Is there any workaround for this to avoid this format exception problem?
Thanks in advance,
Kapil
This is an even bigger issue when dealing with databases and storing data in other cultures too. We initially had a problem in that the Spanish version of our software wouldn't read infinity properly, and would store infinity as the symbol, instead of the word. Even when trying to force it onto the english culture, it appeared broken.
We then saw this issue crop up on Windows 10 in the english culture, where the infinity symbol would now be saved in the database. This issue has the potential to cause problems across Windows versions and across cultures.
The safest thing to do is store and retrieve data, whether in a file or a database, using CultureInfo.InvariantCulture. This way it will always be as you expect it.
If you already have a problem in files/database, then you could run a fairly simple script to seek out the 'Double|∞' and replace it with 'Double|Infinity' which is the invariant type.
This will save you from future problems
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));
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'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.