Two Countries Separated by a Common Parser
-
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:
Been there before! Another one to be aware of is what Italian does with date->string conversion:
DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss")For some reason (in .net2) the colons get converted to periods under it-IT culture making a database update fail using CONVERT(DATETIME, dt, 120) Don't know if this is a feature or a bug!"An eye for an eye only ends up making the whole world blind"
-
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:
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.
Wow, that's a perfect system to handle the national debt!
My .NET Business Application Framework My Home Page My Younger Son & His "PET"
-
Ian Shlasko wrote:
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.
Wow, that's a perfect system to handle the national debt!
My .NET Business Application Framework My Home Page My Younger Son & His "PET"
Now if only it would work on my monthly rent.
-
Now if only it would work on my monthly rent.
-
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
