Two Countries Separated by a Common Parser
-
Personally I'm glad my rent's low enough that this bug wouldn't affect it.
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 must not live in Manhattan, where anyone making less than $75k is pretty much below the poverty ilne :)
-
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 sitting in Nottingham, UK, and tried to reproduce this with a simple console app. Failed to do so. :) Always get the leading digit be it 1 or 2-9. Just thought I'd try both Convert.ToDouble() and double.Parse() to see if they were different.
Regards David R
-
You must not live in Manhattan, where anyone making less than $75k is pretty much below the poverty ilne :)
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 sitting in Nottingham, UK, and tried to reproduce this with a simple console app. Failed to do so. :) Always get the leading digit be it 1 or 2-9. Just thought I'd try both Convert.ToDouble() and double.Parse() to see if they were different.
Regards David R
riced wrote:
I'm sitting in Nottingham, UK
You're not on the right meridian, try London or Newcastle. :)
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
-
riced wrote:
I'm sitting in Nottingham, UK
You're not on the right meridian, try London or Newcastle. :)
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
-
:thumbsup: Spookily, I was in London at the weekend, and am going to Newcastle next weekend. :)
Regards David R
Just post in the subtle bags forum if you need more city trip advice... and don't forget to try
DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss")wherever you go. This site is in desparate need of some touristic articles. :)Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
-
: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.