Two Countries Separated by a Common Parser
-
:thumbsup: Spookily, I was in London at the weekend, and am going to Newcastle next weekend. :)
Regards David R
Typical timing - I'm buggering off to France for the week, so won't be in Newcastle this weekend. Whereabouts are you going to be staying?
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Typical timing - I'm buggering off to France for the week, so won't be in Newcastle this weekend. Whereabouts are you going to be staying?
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Typical timing - I'm buggering off to France for the week, so won't be in Newcastle this weekend. Whereabouts are you going to be staying?
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Sadly or not DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss") is working fine in France. On a sidenote, I've already had this problem in my app where I had to parse numbers. I chose a standard to store them as strings (en-US, in xml config files and other things where you need to store strings) and forced the app to run en-US. It saves you a lot of time and debugging :)
-
This one was driving me insane for about two months... (Context: C#, .NET 3.5) I'm here in NYC, writing software for some guys in our London office... Pretty standard number-crunching and report-generating. Nothing especially fancy... So I release one of the report generators, and it works just fine here, but for some reason, one of my users in London is getting much smaller numbers in the output. After lots of back-and-forth (Communication is rather slow, and vacations never seem to overlap), we figured out that his numbers were mysteriously losing digits. I'm not talking loss of precision here... A dollar amount that showed up as $1,859k on my machine was showing up as $859k on his. The first digit was just gone. After weeks of this, between other projects, I finally got a chance to remote-desktop into his machine and do some hands-on testing. Of course, once I had direct access, it took five minutes to trace and fix. The line where the digit was lost, was just a copy from one DataTable to another. The only trick was that the source "number" was in string format (Because of the database I grabbed it from), and it was copying over to a numeric field. Shouldn't cause any problems, right? .NET does a simple Convert.ToDouble() in the background and we all go home happy... Nope. APPARENTLY, when you do that on a computer with UK regional settings, it strips out a leading "1" in the translation. No other digits. Just the first "1". "199027" becomes 99027... "1112512" becomes 112512... "100888" becomes 888... I changed it to a double.Parse() and got the same result. Only after explicitly specifying NumberFormatInfo.InvariantInfo did it start to behave. So what does the UK have against the number one? :laugh:
I've ran into a semi-related issue. With the default US parser the 1.1 Framework will correctly parse "2009_04_01", the 2.0 framework will not unless I replace the _'s with spaces.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
This one was driving me insane for about two months... (Context: C#, .NET 3.5) I'm here in NYC, writing software for some guys in our London office... Pretty standard number-crunching and report-generating. Nothing especially fancy... So I release one of the report generators, and it works just fine here, but for some reason, one of my users in London is getting much smaller numbers in the output. After lots of back-and-forth (Communication is rather slow, and vacations never seem to overlap), we figured out that his numbers were mysteriously losing digits. I'm not talking loss of precision here... A dollar amount that showed up as $1,859k on my machine was showing up as $859k on his. The first digit was just gone. After weeks of this, between other projects, I finally got a chance to remote-desktop into his machine and do some hands-on testing. Of course, once I had direct access, it took five minutes to trace and fix. The line where the digit was lost, was just a copy from one DataTable to another. The only trick was that the source "number" was in string format (Because of the database I grabbed it from), and it was copying over to a numeric field. Shouldn't cause any problems, right? .NET does a simple Convert.ToDouble() in the background and we all go home happy... Nope. APPARENTLY, when you do that on a computer with UK regional settings, it strips out a leading "1" in the translation. No other digits. Just the first "1". "199027" becomes 99027... "1112512" becomes 112512... "100888" becomes 888... I changed it to a double.Parse() and got the same result. Only after explicitly specifying NumberFormatInfo.InvariantInfo did it start to behave. So what does the UK have against the number one? :laugh:
Looks like the PositiveSign character on this specific machine is "1".
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com link -
Looks like the PositiveSign character on this specific machine is "1".
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com linkYou can verify this by opening :
HKEY_CURRENT_USER\Control Panel\Internationaland checking the value of thesPositiveSignentry.Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com link -
Let me know when you're next up. We may be able to grab a drink - I know Gosforth well.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Ugh no. I'm in Johnstown pa, which has ~35k in the city and immediately surrounding suburbs. Entry level rents in the decent+ parts of town run $400-600ish; only huge houses and luxury apts rent for 4 figures around here.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
I'm paying $450 for that; which is a bit on the high end for the neighborhood because it's a first floor location and the bulk of appartments hereare 2nd story above owner/business. That said, for an unfirnished apt ~1000sqft would only cost $50-100ish more/mo.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
You can verify this by opening :
HKEY_CURRENT_USER\Control Panel\Internationaland checking the value of thesPositiveSignentry.Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com linkThe reg key is blank, but nice try :) Believe it or not, this code:
Console.WriteLine("Culture = " + System.Threading.Thread.CurrentThread.CurrentCulture.ToString());
string testString = "12345";
decimal converted = Convert.ToDecimal(testString);
Console.WriteLine("{0} --> {1}", testString, converted);In a console app targeting .NET 3.5, produces this output:
Culture = en-GB
12345 --> 2345 -
The reg key is blank, but nice try :) Believe it or not, this code:
Console.WriteLine("Culture = " + System.Threading.Thread.CurrentThread.CurrentCulture.ToString());
string testString = "12345";
decimal converted = Convert.ToDecimal(testString);
Console.WriteLine("{0} --> {1}", testString, converted);In a console app targeting .NET 3.5, produces this output:
Culture = en-GB
12345 --> 2345Ahhh, found a permanent fix... The registry key showed up properly, but something was obviously amiss elsewhere... http://social.microsoft.com/Forums/en-US/netfxbcl/thread/4f52ff21-2afe-41c8-aa4e-61acd32dc4a2/ Changed the problem computer's regional settings to something else, then back...
-
This one was driving me insane for about two months... (Context: C#, .NET 3.5) I'm here in NYC, writing software for some guys in our London office... Pretty standard number-crunching and report-generating. Nothing especially fancy... So I release one of the report generators, and it works just fine here, but for some reason, one of my users in London is getting much smaller numbers in the output. After lots of back-and-forth (Communication is rather slow, and vacations never seem to overlap), we figured out that his numbers were mysteriously losing digits. I'm not talking loss of precision here... A dollar amount that showed up as $1,859k on my machine was showing up as $859k on his. The first digit was just gone. After weeks of this, between other projects, I finally got a chance to remote-desktop into his machine and do some hands-on testing. Of course, once I had direct access, it took five minutes to trace and fix. The line where the digit was lost, was just a copy from one DataTable to another. The only trick was that the source "number" was in string format (Because of the database I grabbed it from), and it was copying over to a numeric field. Shouldn't cause any problems, right? .NET does a simple Convert.ToDouble() in the background and we all go home happy... Nope. APPARENTLY, when you do that on a computer with UK regional settings, it strips out a leading "1" in the translation. No other digits. Just the first "1". "199027" becomes 99027... "1112512" becomes 112512... "100888" becomes 888... I changed it to a double.Parse() and got the same result. Only after explicitly specifying NumberFormatInfo.InvariantInfo did it start to behave. So what does the UK have against the number one? :laugh:
-
This one was driving me insane for about two months... (Context: C#, .NET 3.5) I'm here in NYC, writing software for some guys in our London office... Pretty standard number-crunching and report-generating. Nothing especially fancy... So I release one of the report generators, and it works just fine here, but for some reason, one of my users in London is getting much smaller numbers in the output. After lots of back-and-forth (Communication is rather slow, and vacations never seem to overlap), we figured out that his numbers were mysteriously losing digits. I'm not talking loss of precision here... A dollar amount that showed up as $1,859k on my machine was showing up as $859k on his. The first digit was just gone. After weeks of this, between other projects, I finally got a chance to remote-desktop into his machine and do some hands-on testing. Of course, once I had direct access, it took five minutes to trace and fix. The line where the digit was lost, was just a copy from one DataTable to another. The only trick was that the source "number" was in string format (Because of the database I grabbed it from), and it was copying over to a numeric field. Shouldn't cause any problems, right? .NET does a simple Convert.ToDouble() in the background and we all go home happy... Nope. APPARENTLY, when you do that on a computer with UK regional settings, it strips out a leading "1" in the translation. No other digits. Just the first "1". "199027" becomes 99027... "1112512" becomes 112512... "100888" becomes 888... I changed it to a double.Parse() and got the same result. Only after explicitly specifying NumberFormatInfo.InvariantInfo did it start to behave. So what does the UK have against the number one? :laugh:
Does Your Code Pass The Turkey Test?[^]
cheers, Chris Maunder The Code Project Co-founder Microsoft C++ MVP
-
Does Your Code Pass The Turkey Test?[^]
cheers, Chris Maunder The Code Project Co-founder Microsoft C++ MVP
Nope, not a chance... Only designed to run in the US and UK, since that's where our six-person group has offices. And as I posted in another part of this thread, turned out the problem was his machine... The sPositiveSign reg-key was correctly blank, but somewhere else, the machine had decided that "1" = "+"... I flipped region settings to US and back, and it fixed it.
-
Does Your Code Pass The Turkey Test?[^]
cheers, Chris Maunder The Code Project Co-founder Microsoft C++ MVP
Nope. I've asked about making it internationalization ready and been nixed from above. If policy ever changes, and it turns out to be a major issue to implement, it's not my fault.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
This one was driving me insane for about two months... (Context: C#, .NET 3.5) I'm here in NYC, writing software for some guys in our London office... Pretty standard number-crunching and report-generating. Nothing especially fancy... So I release one of the report generators, and it works just fine here, but for some reason, one of my users in London is getting much smaller numbers in the output. After lots of back-and-forth (Communication is rather slow, and vacations never seem to overlap), we figured out that his numbers were mysteriously losing digits. I'm not talking loss of precision here... A dollar amount that showed up as $1,859k on my machine was showing up as $859k on his. The first digit was just gone. After weeks of this, between other projects, I finally got a chance to remote-desktop into his machine and do some hands-on testing. Of course, once I had direct access, it took five minutes to trace and fix. The line where the digit was lost, was just a copy from one DataTable to another. The only trick was that the source "number" was in string format (Because of the database I grabbed it from), and it was copying over to a numeric field. Shouldn't cause any problems, right? .NET does a simple Convert.ToDouble() in the background and we all go home happy... Nope. APPARENTLY, when you do that on a computer with UK regional settings, it strips out a leading "1" in the translation. No other digits. Just the first "1". "199027" becomes 99027... "1112512" becomes 112512... "100888" becomes 888... I changed it to a double.Parse() and got the same result. Only after explicitly specifying NumberFormatInfo.InvariantInfo did it start to behave. So what does the UK have against the number one? :laugh:
Ian Shlasko wrote:
APPARENTLY, when you do that on a computer with UK regional settings, it strips out a leading "1" in the translation. No other digits. Just the first "1". "199027" becomes 99027... "1112512" becomes 112512... "100888" becomes 888... I changed it to a double.Parse() and got the same result. Only after explicitly specifying NumberFormatInfo.InvariantInfo did it start to behave.
That's actually "normal". Us Europeans know quite well the hell that can arise from executing our perfectly working code on PCs with different national settings. :P That kind of problem has been there since the beginning, and will most probably be always there (until the one-world, one-set-of-rules utopia, that is). You would be surprised to see how many commercial high profile software projects break up miserably when run on non-US PCs. The correct solution is using the "invariant" culture (or any similar trick in the framework you're using), as you did. I made a rule of always using that, so hopefully my apps won't break (too much) when run on non-Italian PCs... The real mess arises when you exchange data with other systems/softwares, and those are affect by some cultureinfo problem. Imagine for example two different softwares running on an UK PC: the first software won't work unless you set the culture to UK (because of some internals you cannot change which were not programmed with the cultureinfo problem in mind), but exports some data using the invariant culture settings. The second imports the data, but only using the PC's culture settings... all breaks up. You need some ad-hoc middleware to convert the data format.
2+2=5 for very large amounts of 2 (always loved that one hehe!)
-
This one was driving me insane for about two months... (Context: C#, .NET 3.5) I'm here in NYC, writing software for some guys in our London office... Pretty standard number-crunching and report-generating. Nothing especially fancy... So I release one of the report generators, and it works just fine here, but for some reason, one of my users in London is getting much smaller numbers in the output. After lots of back-and-forth (Communication is rather slow, and vacations never seem to overlap), we figured out that his numbers were mysteriously losing digits. I'm not talking loss of precision here... A dollar amount that showed up as $1,859k on my machine was showing up as $859k on his. The first digit was just gone. After weeks of this, between other projects, I finally got a chance to remote-desktop into his machine and do some hands-on testing. Of course, once I had direct access, it took five minutes to trace and fix. The line where the digit was lost, was just a copy from one DataTable to another. The only trick was that the source "number" was in string format (Because of the database I grabbed it from), and it was copying over to a numeric field. Shouldn't cause any problems, right? .NET does a simple Convert.ToDouble() in the background and we all go home happy... Nope. APPARENTLY, when you do that on a computer with UK regional settings, it strips out a leading "1" in the translation. No other digits. Just the first "1". "199027" becomes 99027... "1112512" becomes 112512... "100888" becomes 888... I changed it to a double.Parse() and got the same result. Only after explicitly specifying NumberFormatInfo.InvariantInfo did it start to behave. So what does the UK have against the number one? :laugh:
This is bound to fail with a lot of cultures, as the decimal separator is interpreted depending on cultural settings of the OS every time. If you really have to go through strings, you need to make sure you have a common culture setting for string creation AND parsing: Here's a short snippet that parses a double using the invariant culture settings. If you'd take another culture, the dot might be interpreted differently. Here's a snippet that parses the same string using invariant and German culture settings:
public void TestParsing()
{
NumberFormatInfo provider = CultureInfo.InvariantCulture.NumberFormat;
double d = Convert.ToDouble("12.15", provider);
Console.Out.WriteLine(d);provider = new CultureInfo("de-de").NumberFormat;
d = Convert.ToDouble("12.15", provider);
Console.Out.WriteLine(d);
}Output:
12.15
1215Cheers, Philipp
NetDrives - Open Source Network Share Management
-
If I remember correctly, in UK they use comma as a decimal separator. 1,859,000 to them is invalid so the parser might be getting confused. Did you check if the input contains any commas ?
VentsyV wrote:
If I remember correctly, in UK they use comma as a decimal separator.
You dont remember correctly, we use the comma as a thousand separator and a decimal point for the decimal separator. Its somewhere weird like Italy that uses the comma as the decimal sep.
-
This one was driving me insane for about two months... (Context: C#, .NET 3.5) I'm here in NYC, writing software for some guys in our London office... Pretty standard number-crunching and report-generating. Nothing especially fancy... So I release one of the report generators, and it works just fine here, but for some reason, one of my users in London is getting much smaller numbers in the output. After lots of back-and-forth (Communication is rather slow, and vacations never seem to overlap), we figured out that his numbers were mysteriously losing digits. I'm not talking loss of precision here... A dollar amount that showed up as $1,859k on my machine was showing up as $859k on his. The first digit was just gone. After weeks of this, between other projects, I finally got a chance to remote-desktop into his machine and do some hands-on testing. Of course, once I had direct access, it took five minutes to trace and fix. The line where the digit was lost, was just a copy from one DataTable to another. The only trick was that the source "number" was in string format (Because of the database I grabbed it from), and it was copying over to a numeric field. Shouldn't cause any problems, right? .NET does a simple Convert.ToDouble() in the background and we all go home happy... Nope. APPARENTLY, when you do that on a computer with UK regional settings, it strips out a leading "1" in the translation. No other digits. Just the first "1". "199027" becomes 99027... "1112512" becomes 112512... "100888" becomes 888... I changed it to a double.Parse() and got the same result. Only after explicitly specifying NumberFormatInfo.InvariantInfo did it start to behave. So what does the UK have against the number one? :laugh:
I'm from the UK and it doesn't happen for me either :p FYI: if you used FXCop, it would remind you to supply the CultureInfo ;-)