CultureInfo.NumericFormat and System.Convert

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

dorminey@gmail.com - 31 Jul 2006 20:44 GMT

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".
}
}
}

Reply to this Message

Nicole Calinoiu - 01 Aug 2006 12:31 GMT

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:
[quoted text clipped - 45 lines]
> }
> }

Reply to this Message

dorminey@gmail.com - 01 Aug 2006 14:52 GMT

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
[quoted text clipped - 54 lines]
> > }
> > }

Reply to this Message

Nicole Calinoiu - 01 Aug 2006 15:48 GMT

> 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
[quoted text clipped - 56 lines]
>> > }
>> > }

Reply to this Message

dorminey@gmail.com - 01 Aug 2006 16:43 GMT

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.
[quoted text clipped - 76 lines]
> >> > }
> >> > }

Reply to this Message

Nicole Calinoiu - 01 Aug 2006 19:46 GMT

> You have a valid point, however this particular application will be
> highly controlled and the install will be regulated down to the
[quoted text clipped - 3 lines]
> 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
[quoted text clipped - 9 lines]
> 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.
[quoted text clipped - 88 lines]
>> >> > }
>> >> > }

Reply to this Message

dorminey@gmail.com - 02 Aug 2006 18:04 GMT

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
[quoted text clipped - 136 lines]
> >> >> > }
> >> >> > }

Reply to this Message

Jim Wooley - 01 Aug 2006 18:28 GMT

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

>> 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.
[quoted text clipped - 15 lines]
> about with it, particularly when adjusting your application's code to
> accomodate their preference takes very little effort

Reply to this Message

CultureInfo.NumericFormat and System.Convert

Free Magazines