Solución:
Cuando los números, las fechas y las horas se formatean en cadenas o se analizan a partir de cadenas, se usa una referencia cultural para determinar cómo se hace. Ej. En el dominante en-US cultura tienes estas representaciones de cadena:
- 1,000,000.00 – un millón con una fracción de dos dígitos
- 29/01/2013 – fecha de esta publicación
En mi culturada-DK) los valores tienen esta representación de cadena:
- 1.000.000,00 – un millón con una fracción de dos dígitos
- 29-01-2013 – fecha de esta publicación
En el sistema operativo Windows, el usuario puede incluso personalizar cómo se formatean los números y la fecha / hora y también puede elegir otra cultura que la de su sistema operativo. El formato utilizado es a elección del usuario, que es como debe ser.
Entonces, cuando formatea un valor para que se muestre al usuario usando, por ejemplo, ToString o String.Format o analizado de una cadena usando DateTime.Parse o Decimal.Parse el valor predeterminado es usar el CultureInfo.CurrentCulture. Esto permite al usuario controlar el formato.
Sin embargo, una gran cantidad de formato y análisis de cadenas en realidad no son cadenas intercambiadas entre la aplicación y el usuario, sino entre la aplicación y algún formato de datos (por ejemplo, un archivo XML o CSV). En ese caso, no desea utilizar CultureInfo.CurrentCulture porque si el formateo y el análisis se realizan con diferentes culturas, puede romperse. En ese caso, desea utilizar CultureInfo.InvariantCulture (que se basa en el en-US cultura). Esto asegura que los valores puedan circular sin problemas.
La razón por la que ReSharper le da la advertencia es que algunos escritores de aplicaciones desconocen esta distinción que puede conducir a resultados no deseados, pero nunca descubren esto porque su CultureInfo.CurrentCulture es en-US que tiene el mismo comportamiento que CultureInfo.InvariantCulture. Sin embargo, tan pronto como la aplicación se use en otra cultura donde existe la posibilidad de usar una cultura para formatear y otra para analizar, la aplicación puede fallar.
Entonces, para resumirlo:
- Usar
CultureInfo.CurrentCulture(el valor predeterminado) si está formateando o analizando una cadena de usuario. - Usar
CultureInfo.InvariantCulturesi está formateando o analizando una cadena que debería ser analizable por una pieza de software. - Rara vez use una cultura nacional específica porque el usuario no puede controlar cómo se realiza el formato y el análisis.
No todas las culturas usan el mismo formato para fechas y valores decimales / monetarios.
Esto le importará cuando convierta valores de entrada (leer) que se almacenan como cadenas para DateTime, float, double o decimal. También importará si intenta formatear los tipos de datos antes mencionados en cadenas (escribir) para exhibición o almacenamiento.
Si sabe de antemano en qué cultura específica estarán sus fechas y valores decimales / de moneda, puede usar esa CultureInfo propiedad (es decir CultureInfo("en-GB")). Por ejemplo, si espera una entrada de usuario.
los CultureInfo.InvariantCulture La propiedad se usa si está formateando o analizando una cadena que debería ser analizable por un software independiente de la configuración local del usuario.
El valor predeterminado es CultureInfo.InstalledUICulture por lo que CultureInfo predeterminado depende de la configuración del sistema operativo en ejecución. Es por eso que siempre debe asegurarse de que la información cultural se ajuste a su intención (consulte la respuesta de Martin para obtener una buena guía).
- CultureInfo.InvariantCulture Ejemplo
- CultureInfo.InvariantCulture en StackOverflow
- CultureInfo.InvariantCulture Artículo de MSDN
- Nombres de información cultural predefinidos
Según Microsoft:
La propiedad CultureInfo.InvariantCulture no es una cultura neutral ni específica. Es el tercer tipo de cultura que es insensible a la cultura. Está asociado con el idioma inglés pero no con un país o región.
(de http://msdn.microsoft.com/en-us/library/4c5zdc6a(vs.71).aspx)
Entonces, InvariantCulture es similar a la cultura “en-US” pero no exactamente lo mismo. Si tú escribes:
var d = DateTime.Now;
var s1 = d.ToString(CultureInfo.InvariantCulture); // "05/21/2014 22:09:28"
var s2 = d.ToString(new CultureInfo("en-US")); // "5/21/2014 10:09:28 PM"
entonces s1 y s2 tendrán un formato similar pero InvariantCulture agrega ceros a la izquierda y “en-US” usa AM o PM.
Por lo tanto, InvariantCulture es mejor para uso interno cuando, por ejemplo, guarda una fecha en un archivo de texto o analiza datos. Y una CultureInfo especificada es mejor cuando presenta datos (fecha, moneda …) al usuario final.