CultureInfo.NumericFormat and System.Convert

[dorminey]

I am having a problem where a few machines at my company are failing on
the following line of code:

double dbl = System.Convert.ToDouble("0");

I have traced it to the fact that for the thread's current culture
("en-US") the NumberFormat.PositiveSign is in fact set to "0" instead
of "+".

In .net 1.1 there was a culture.nlp file where this info was stored but
it has changed in 2.0. Where is this "0" for PositiveSign coming from
and why is it defaulted to zero on a small minority of boxes at my
workplace? Below is a sample program that explains all. Thanks to
anyone who can help.

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using System.Globalization;

namespace ConsoleApplication10
{
class Program
{
static void Main(string[] args)
{
//this line fails on several machines at LockHeed
//it will work on most machines on which it is run
double dbl = Convert.ToDouble("0");

//here we can reproduce the error we see on the problem
machines
CultureInfo ci = new
System.Globalization.CultureInfo("en-US");
ci.NumberFormat.PositiveSign = "0";

Thread.CurrentThread.CurrentCulture = ci;

dbl = Convert.ToDouble("0");

//The problem we are seeing is that on the problem machines
//the PositiveSign property is "0" by default instead of
the
//proper value of "+". The culture on these boxes is
"en-US".
}
}
}

 

[Nicole Calinoiu]

By default, when you create a new instance of a CultureInfo that matches the
regional settings for the current user, any regional settings customizations
will be copied to your new CultureInfo instance. If this is where your 0
positive sign is originating, the problem can be avoided by using the
CultureInfo constructor overload that allows you to specify that regional
settings customizations should not be copied. e.g.:

CultureInfo ci = new System.Globalization.CultureInfo("en-US", false);

 

[dorminey]

I'll give that a shot. However, it would be preferable if I didn't
have to set the culture of my threads manually in the first place.
Convert.ToDouble("0") should just work. I'd like to find out where I
can fix the problem with the machine or the .NET framework install that
is causing this.

By default, when you create a new instance of a CultureInfo that matches the
regional settings for the current user, any regional settings customizations
will be copied to your new CultureInfo instance. If this is where your 0
positive sign is originating, the problem can be avoided by using the
CultureInfo constructor overload that allows you to specify that regional
settings customizations should not be copied. e.g.:

CultureInfo ci = new System.Globalization.CultureInfo("en-US", false);

I am having a problem where a few machines at my company are failing on
the following line of code:

double dbl = System.Convert.ToDouble("0");

I have traced it to the fact that for the thread's current culture
("en-US") the NumberFormat.PositiveSign is in fact set to "0" instead
of "+".

In .net 1.1 there was a culture.nlp file where this info was stored but
it has changed in 2.0. Where is this "0" for PositiveSign coming from
and why is it defaulted to zero on a small minority of boxes at my
workplace? Below is a sample program that explains all. Thanks to
anyone who can help.

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using System.Globalization;

namespace ConsoleApplication10
{
class Program
{
static void Main(string[] args)
{
//this line fails on several machines at LockHeed
//it will work on most machines on which it is run
double dbl = Convert.ToDouble("0");

//here we can reproduce the error we see on the problem
machines
CultureInfo ci = new
System.Globalization.CultureInfo("en-US");
ci.NumberFormat.PositiveSign = "0";

Thread.CurrentThread.CurrentCulture = ci;

dbl = Convert.ToDouble("0");

//The problem we are seeing is that on the problem machines
//the PositiveSign property is "0" by default instead of
the
//proper value of "+". The culture on these boxes is
"en-US".
}
}
}

 

[Nicole Calinoiu]

I'll give that a shot. However, it would be preferable if I didn't
have to set the culture of my threads manually in the first place.
Convert.ToDouble("0") should just work.

Not really. Parsing is very culture-sensitive and, inconvenient as it may
seem to you at the moment, the refusal of the .NET framework to parse a
positive number sign that happens to be "0" to the value 0 is probably the
best choice of behaviour the designers could have made. For example, if you
happened to choose "1" as the positive number sign, what should the value
"1" be parsed to?

I'd like to find out where I
can fix the problem with the machine or the .NET framework install that
is causing this.

What makes you think there's necessarily a problem? If the users have
adjusted their preferred positive sign, why would you want to muck about
with it, particularly when adjusting your application's code to accomodate
their preference takes very little effort.

By default, when you create a new instance of a CultureInfo that matches
the
regional settings for the current user, any regional settings
customizations
will be copied to your new CultureInfo instance. If this is where your 0
positive sign is originating, the problem can be avoided by using the
CultureInfo constructor overload that allows you to specify that regional
settings customizations should not be copied. e.g.:

CultureInfo ci = new System.Globalization.CultureInfo("en-US", false);

I am having a problem where a few machines at my company are failing on
the following line of code:

double dbl = System.Convert.ToDouble("0");

I have traced it to the fact that for the thread's current culture
("en-US") the NumberFormat.PositiveSign is in fact set to "0" instead
of "+".

In .net 1.1 there was a culture.nlp file where this info was stored but
it has changed in 2.0. Where is this "0" for PositiveSign coming from
and why is it defaulted to zero on a small minority of boxes at my
workplace? Below is a sample program that explains all. Thanks to
anyone who can help.

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using System.Globalization;

namespace ConsoleApplication10
{
class Program
{
static void Main(string[] args)
{
//this line fails on several machines at LockHeed
//it will work on most machines on which it is run
double dbl = Convert.ToDouble("0");

//here we can reproduce the error we see on the problem
machines
CultureInfo ci = new
System.Globalization.CultureInfo("en-US");
ci.NumberFormat.PositiveSign = "0";

Thread.CurrentThread.CurrentCulture = ci;

dbl = Convert.ToDouble("0");

//The problem we are seeing is that on the problem machines
//the PositiveSign property is "0" by default instead of
the
//proper value of "+". The culture on these boxes is
"en-US".
}
}
}

 

[dorminey]

You have a valid point, however this particular application will be
highly controlled and the install will be regulated down to the
military grade hardware. The culture info of our OS is one of the
things we can take for granted. A flight engineer who decides to mess
with the culture settings would likely be reprimanded. The users who
are currently experiencing the problem didn't set this and would like
to know how to change it back to "+".

At the moment I have no idea how to set the positiveSign property
outside of code and would love to find out how to do so. I think that
99.999% of coders would never have worried about this in the first
place. If it were even remotely common I would have found postings
about it already since parsing is a very common operation. Do you
commonly set the cultures on all of your threads?

I have no problem with the designers picking up a "0" as the positive
sign and running with it. I would do it too. But the user who figured
out how to set his positive sign property to zero would likely expect
strange behavior as "0" is universally a number in any culture using
arabic numerals (having just used the word arabic I've made sure
homeland security is now reading our thread. Hi guys). How would he
then express the concept of "nothing" mathematically? (or in your
example below, how would he express the concept of a single entity
mathematically if "1" were the positive sign?) If we were talking
about decimal point vs. comma, I could more easily see a problem.

Anyway, I am still curious where this setting comes from and why in
"en-US" of all places, it is set to "0".

I'll give that a shot. However, it would be preferable if I didn't
have to set the culture of my threads manually in the first place.
Convert.ToDouble("0") should just work.

Not really. Parsing is very culture-sensitive and, inconvenient as it may
seem to you at the moment, the refusal of the .NET framework to parse a
positive number sign that happens to be "0" to the value 0 is probably the
best choice of behaviour the designers could have made. For example, if you
happened to choose "1" as the positive number sign, what should the value
"1" be parsed to?

I'd like to find out where I
can fix the problem with the machine or the .NET framework install that
is causing this.

What makes you think there's necessarily a problem? If the users have
adjusted their preferred positive sign, why would you want to muck about
with it, particularly when adjusting your application's code to accomodate
their preference takes very little effort.

By default, when you create a new instance of a CultureInfo that matches
the
regional settings for the current user, any regional settings
customizations
will be copied to your new CultureInfo instance. If this is where your 0
positive sign is originating, the problem can be avoided by using the
CultureInfo constructor overload that allows you to specify that regional
settings customizations should not be copied. e.g.:

CultureInfo ci = new System.Globalization.CultureInfo("en-US", false);



I am having a problem where a few machines at my company are failing on
the following line of code:

double dbl = System.Convert.ToDouble("0");

I have traced it to the fact that for the thread's current culture
("en-US") the NumberFormat.PositiveSign is in fact set to "0" instead
of "+".

In .net 1.1 there was a culture.nlp file where this info was stored but
it has changed in 2.0. Where is this "0" for PositiveSign coming from
and why is it defaulted to zero on a small minority of boxes at my
workplace? Below is a sample program that explains all. Thanks to
anyone who can help.

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using System.Globalization;

namespace ConsoleApplication10
{
class Program
{
static void Main(string[] args)
{
//this line fails on several machines at LockHeed
//it will work on most machines on which it is run
double dbl = Convert.ToDouble("0");

//here we can reproduce the error we see on the problem
machines
CultureInfo ci = new
System.Globalization.CultureInfo("en-US");
ci.NumberFormat.PositiveSign = "0";

Thread.CurrentThread.CurrentCulture = ci;

dbl = Convert.ToDouble("0");

//The problem we are seeing is that on the problem machines
//the PositiveSign property is "0" by default instead of
the
//proper value of "+". The culture on these boxes is
"en-US".
}
}
}

 

[Jim Wooley]

Just to throw my $.02 in, be aware of the fact that $0.02 will fail when
passed to Double.TryParse. See http://devauthority.com/blogs/jwooley/archive/2006/03/15/788.aspx
for details on how to work around this.
Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx

 

[Nicole Calinoiu]

You have a valid point, however this particular application will be
highly controlled and the install will be regulated down to the
military grade hardware. The culture info of our OS is one of the
things we can take for granted. A flight engineer who decides to mess
with the culture settings would likely be reprimanded. The users who
are currently experiencing the problem didn't set this and would like
to know how to change it back to "+".

That puts a very different spin on things... If the users didn't make the
change deliberately, it's very likely that some rather impolite software
changed the setting on their behalf.

At the moment I have no idea how to set the positiveSign property
outside of code and would love to find out how to do so.

Assuming that the problem does lie in the regional settings, you should be
able to change it back to an empty string by editing the sPositiveSign value
under the HKEY_CURRENT_USER\Control Panel\International registry key.

I think that
99.999% of coders would never have worried about this in the first
place. If it were even remotely common I would have found postings
about it already since parsing is a very common operation. Do you
commonly set the cultures on all of your threads?

Yes, and I also use parsing method overloads that allow me to specify the
culture settings explicitly. However, it's true that many folks don't, but
they're probably not running into the same problem as you are given that
setting "0" as the positive sign is likely to be rare.

I have no problem with the designers picking up a "0" as the positive
sign and running with it. I would do it too. But the user who figured
out how to set his positive sign property to zero would likely expect
strange behavior as "0" is universally a number in any culture using
arabic numerals (having just used the word arabic I've made sure
homeland security is now reading our thread. Hi guys). How would he
then express the concept of "nothing" mathematically? (or in your
example below, how would he express the concept of a single entity
mathematically if "1" were the positive sign?) If we were talking
about decimal point vs. comma, I could more easily see a problem.

Anyway, I am still curious where this setting comes from and why in
"en-US" of all places, it is set to "0".

If it is due to a regional settings modification, it's being picked up for
en-US simply because that's the base culture for the current user's regional
settings under Windows.

I'll give that a shot. However, it would be preferable if I didn't
have to set the culture of my threads manually in the first place.
Convert.ToDouble("0") should just work.

Not really. Parsing is very culture-sensitive and, inconvenient as it
may
seem to you at the moment, the refusal of the .NET framework to parse a
positive number sign that happens to be "0" to the value 0 is probably
the
best choice of behaviour the designers could have made. For example, if
you
happened to choose "1" as the positive number sign, what should the value
"1" be parsed to?

I'd like to find out where I
can fix the problem with the machine or the .NET framework install that
is causing this.

What makes you think there's necessarily a problem? If the users have
adjusted their preferred positive sign, why would you want to muck about
with it, particularly when adjusting your application's code to
accomodate
their preference takes very little effort.

Nicole Calinoiu wrote:
By default, when you create a new instance of a CultureInfo that
matches
the
regional settings for the current user, any regional settings
customizations
will be copied to your new CultureInfo instance. If this is where
your 0
positive sign is originating, the problem can be avoided by using the
CultureInfo constructor overload that allows you to specify that
regional
settings customizations should not be copied. e.g.:

CultureInfo ci = new System.Globalization.CultureInfo("en-US", false);



I am having a problem where a few machines at my company are failing
on
the following line of code:

double dbl = System.Convert.ToDouble("0");

I have traced it to the fact that for the thread's current culture
("en-US") the NumberFormat.PositiveSign is in fact set to "0"
instead
of "+".

In .net 1.1 there was a culture.nlp file where this info was stored
but
it has changed in 2.0. Where is this "0" for PositiveSign coming
from
and why is it defaulted to zero on a small minority of boxes at my
workplace? Below is a sample program that explains all. Thanks to
anyone who can help.

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using System.Globalization;

namespace ConsoleApplication10
{
class Program
{
static void Main(string[] args)
{
//this line fails on several machines at LockHeed
//it will work on most machines on which it is run
double dbl = Convert.ToDouble("0");

//here we can reproduce the error we see on the problem
machines
CultureInfo ci = new
System.Globalization.CultureInfo("en-US");
ci.NumberFormat.PositiveSign = "0";

Thread.CurrentThread.CurrentCulture = ci;

dbl = Convert.ToDouble("0");

//The problem we are seeing is that on the problem
machines
//the PositiveSign property is "0" by default instead of
the
//proper value of "+". The culture on these boxes is
"en-US".
}
}
}

 

[dorminey]

Thanks for the help Nicole. Microsoft came through with the registry
setting this morning and we changed it. The interesting thing is that
we had found the setting before but it was blank on all the machines;
even the ones that didn't work. Microsoft support told us to set it to
"0" and then back to blank. We did so and the problem computers
magically worked. I can only think that .NET caches this info
somewhere and it was corrupted somehow.

I had been under the impression that in previous versions of the
framework this kind of information was kept in a separate place than
the OS. Even now I know that it will look in %WINNT%\Globalization for
..nlp files (even though it appears empty on our boxes currently).
However after playing with this registry setting and VS2003 I realize
that these settings have always been picked up from the registry.

I have in the past been concerned with culture settings when parsing
numbers containing decimal points or monetary sybols, etc.. I will be
more concerned about it in general after this experience. It would
seem that even when the culture of the target machines are a "given",
things can go wrong (though here we have more control than usual).

You have a valid point, however this particular application will be
highly controlled and the install will be regulated down to the
military grade hardware. The culture info of our OS is one of the
things we can take for granted. A flight engineer who decides to mess
with the culture settings would likely be reprimanded. The users who
are currently experiencing the problem didn't set this and would like
to know how to change it back to "+".

That puts a very different spin on things... If the users didn't make the
change deliberately, it's very likely that some rather impolite software
changed the setting on their behalf.

At the moment I have no idea how to set the positiveSign property
outside of code and would love to find out how to do so.

Assuming that the problem does lie in the regional settings, you should be
able to change it back to an empty string by editing the sPositiveSign value
under the HKEY_CURRENT_USER\Control Panel\International registry key.

I think that
99.999% of coders would never have worried about this in the first
place. If it were even remotely common I would have found postings
about it already since parsing is a very common operation. Do you
commonly set the cultures on all of your threads?

Yes, and I also use parsing method overloads that allow me to specify the
culture settings explicitly. However, it's true that many folks don't, but
they're probably not running into the same problem as you are given that
setting "0" as the positive sign is likely to be rare.

I have no problem with the designers picking up a "0" as the positive
sign and running with it. I would do it too. But the user who figured
out how to set his positive sign property to zero would likely expect
strange behavior as "0" is universally a number in any culture using
arabic numerals (having just used the word arabic I've made sure
homeland security is now reading our thread. Hi guys). How would he
then express the concept of "nothing" mathematically? (or in your
example below, how would he express the concept of a single entity
mathematically if "1" were the positive sign?) If we were talking
about decimal point vs. comma, I could more easily see a problem.

Anyway, I am still curious where this setting comes from and why in
"en-US" of all places, it is set to "0".

If it is due to a regional settings modification, it's being picked up for
en-US simply because that's the base culture for the current user's regional
settings under Windows.

I'll give that a shot. However, it would be preferable if I didn't
have to set the culture of my threads manually in the first place.
Convert.ToDouble("0") should just work.

Not really. Parsing is very culture-sensitive and, inconvenient as it
may
seem to you at the moment, the refusal of the .NET framework to parse a
positive number sign that happens to be "0" to the value 0 is probably
the
best choice of behaviour the designers could have made. For example, if
you
happened to choose "1" as the positive number sign, what should the value
"1" be parsed to?


I'd like to find out where I
can fix the problem with the machine or the .NET framework install that
is causing this.

What makes you think there's necessarily a problem? If the users have
adjusted their preferred positive sign, why would you want to muck about
with it, particularly when adjusting your application's code to
accomodate
their preference takes very little effort.




Nicole Calinoiu wrote:
By default, when you create a new instance of a CultureInfo that
matches
the
regional settings for the current user, any regional settings
customizations
will be copied to your new CultureInfo instance. If this is where
your 0
positive sign is originating, the problem can be avoided by using the
CultureInfo constructor overload that allows you to specify that
regional
settings customizations should not be copied. e.g.:

CultureInfo ci = new System.Globalization.CultureInfo("en-US", false);



I am having a problem where a few machines at my company are failing
on
the following line of code:

double dbl = System.Convert.ToDouble("0");

I have traced it to the fact that for the thread's current culture
("en-US") the NumberFormat.PositiveSign is in fact set to "0"
instead
of "+".

In .net 1.1 there was a culture.nlp file where this info was stored
but
it has changed in 2.0. Where is this "0" for PositiveSign coming
from
and why is it defaulted to zero on a small minority of boxes at my
workplace? Below is a sample program that explains all. Thanks to
anyone who can help.

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using System.Globalization;

namespace ConsoleApplication10
{
class Program
{
static void Main(string[] args)
{
//this line fails on several machines at LockHeed
//it will work on most machines on which it is run
double dbl = Convert.ToDouble("0");

//here we can reproduce the error we see on the problem
machines
CultureInfo ci = new
System.Globalization.CultureInfo("en-US");
ci.NumberFormat.PositiveSign = "0";

Thread.CurrentThread.CurrentCulture = ci;

dbl = Convert.ToDouble("0");

//The problem we are seeing is that on the problem
machines
//the PositiveSign property is "0" by default instead of
the
//proper value of "+". The culture on these boxes is
"en-US".
}
}
}