Jon Skeet: Coding Blog

The ideal solution could be an attribute that could be applied to a method, class or whole assembly telling the default culture when not specified in a call.

It could actually be done, i think by using something like Cecil to create a post-compilation tool for that. Same as the binary rewriter that microsoft have in "Code Contracts for .NET" ( blogs.msdn.com/.../devlabs-code-contracts-for-net.aspx )

As an alternative to having to pass cultureinfo/locale, timezoneinfo/timezone, and encoding/charset for *each* call, what about marking up a method call with an attribute that specifies these?

The method being called could use system default values, but if it's called with this attribute, those defaults would return the values specified in the attribute.

It's also probably much too late for this to be implemented, but it might strike a decent compromise/balance among the options you listed.

db

You can, of course, use the Thread.CurrentCulture to set a default cultureinfo/locale.

I live in Belgium, so (luckily) I have to deal with this kind of stuff all the time.

I've grown used to always using the overloads that take a CultureInfo. I actually think that Microsoft has changed the defaults to InvariantCulture in .NET 4.0.

A good way to find places in your code where you forgot this, is to use Static Analysis/FxCop. That will catch it.

Brings back memories of "date to string to date" problems in ASP...

Even though I would probably hate it, I think the 'no default' option is the way to go. I'm all for abstracting away gruesome details, but not if they come back to haunt you. In production.

I quite like the idea of being able to choose [Neutral/System/Calling Assembly/Specific].

The fun part of this is that 'the rest of the world' - understand non american/english people - know this !

Ok it's a bit exagerated.

Actually people know the problem but not the solution.

Since in France, the decimal separator is ',' I often see this :

value.ToString().Replace(',', '.');

How ugly !

The rule of thumb is still simple : When dealing with strings, ALWAYS provide a cutlure.

- If the string is meant to be read by people, use CurrentCulture (or appropriate one).

- If the string is intended to be used by another system, use InvariantCulture

That's all

Pingback from  Arjan`s World    » LINKBLOG for May 15, 2009

I think you could make Thread.CurrentCulture useful to combine it with some scope control. So something like this:

using (new CultureScope("nl-BE"))

{

 ...

}

This code would first save the current thread culture, then set the new (nl-BE) culture. After that, the code (...) is executed and finally the saved culture is made current again.