J'ai un problème avec AC # Assembly (.NET 2.0 écrit à l'aide de Visual Studio 2005) qui est installé sur un serveur britannique et doit utiliser des paramètres régionaux britanniques.
Quel est mon code pour convertir une date sous la forme jj / mm / aaaa dans UTC. c'est-à-dire yyyy-mm-dd. Le problème est apparu avec des dates comme le 16/02/2010 où le composant n'a pas pu convertir la date et l'erreur renvoyée. Après avoir débogué, je me suis rendu compte que, pour une raison étrange, le cultureInfo renvoyé par System.CultureInfo est en-US. P>
Je peux modifier de manière programmative ces paramètres en utilisant: P>
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-GB", false);
Un peu de détails supplémentaires sur le contexte. L'assemblage en question est appelé via Com Interop à partir d'un composant tiers natifs C ++ qui fonctionne comme une application COM +. P> p>
7 Réponses :
Je crois que cela est représenté par System.Globalization.CultureInfo.installduculture, donc si rien d'autre que vous puissiez peut copier cela à la culture actuelle du fil. Je suis surpris que vous ayez trouvé un cas où la culture de threads est différente de la culture installée. Peut-être que votre code est en cours d'exécution dans un processus qui a changé la culture?
Il est possible que le compte exécutif du code a différents paramètres régionaux que la valeur par défaut du système. Avez-vous vérifié cela?
Je ne suis pas sûr que la première suggestion est vraiment très différente de simplement définir la culture explicitement. IT est possible que le compte d'utilisateur soit incorrect, je vérifierai.
Pour définir la culture et la culture de l'UI pour toutes les pages, ajoutez une section de globalisation au fichier web.config, puis définissez les attributs d'uculture et de culture, comme indiqué dans l'exemple suivant:
Le code en question ne fonctionne pas dans ASP.NET, il n'y a donc pas de fichier web.config, je suppose que ce paramètre pourrait également être défini dans le fichier de configuration de l'application. Je vais ajouter des détails supplémentaires à la question sur le contexte d'appel.
Meilleure réponse IMHO, c'est aussi un bon moyen d'obtenir des messages d'erreur chooglables si vous avez des systèmes avec différentes cultures; De plus, vous obtenez des crashs précoces pour System.globalization Bugs associés que vous pourriez avoir dans la base de code
Vous n'êtes pas obligé de changer la culture en courant pour faire la transformation. Si vous êtes certain que la date est sous la forme de "DD / mm / aaaa", vous pouvez utiliser
DateTime dtTemp = DateTime(dateString, CurrentCulture.DateTimeFormat.ShortDatePattern, CurrentCulture.DateTimeFormat);
J'aime cette solution pragmatique au problème et y penser, c'est probablement le meilleur moyen de la mettre en œuvre de toute façon, car les formats d'entrée / sortie sont réellement fixés. J'aimerais toujours savoir pourquoi les paramètres régionaux du système ne fonctionnent pas cependant.
J'ai proposé cette solution de contournement, dans un cas où les paramètres régionaux sélectionnés du système ont chargé un format de "DD / mm / aaaa", mais l'utilisateur avait sélectionné la date à formatée comme "mm / jj / aaaa". Donc, je ne pouvais pas vraiment faire confiance à la culture actuelle. Cela est possible dans Windows 7 et je pense que dans XP aussi.
Fermer, mais pas tout à fait correct; Pour obtenir un "/" / "/", vous devez utiliser le format "DD '/" MM "/" AAAYY ", et spécifier les caractères" / "comme littéraux (en guillemets simples). Le "/" est un caractère de remplacement de format de date (comme "DD", etc.), et est remplacé par le séparateur de date de culture actuelle, qui pourrait être "-" ou ""; Si vous voulez un "/" littéral, c'est-à-dire que je ne veux pas que ce soit remplacé, vous devez inclure dans des guillemets simples.
hmmm, selon le API DOCS :
Lorsqu'un thread est démarré, sa culture est initialement déterminée en utilisant Cette méthode dérive sa locale à partir du (comme son nom l'indique) les paramètres régionaux par défaut de l'utilisateur, que je suppose est dans le panneau de configuration. Note : Ce n'est pas la même chose que les paramètres UI.
getuserdefaultlCid de l'API Windows.
Les assemblages dans .NET Framework sont neutres de la culture.
Quel code essayez-vous de convertir la date?
Si vous utilisez Parse ou Tryparse , essayez de fournir l'argument de culture pour comprendre la date.
Le serveur n'est pas configuré correctement. Panneau de commande + région et langue, onglet de localisation. Changer cela pourrait être un peu délicat. Le serveur peut bien avoir été mal configuré exprès. Parlez d'abord à l'administrateur du serveur avant de faire quoi que ce soit.
Votre plan de secours consiste à utiliser la surcharge de la méthode DateTime.tryParse () qui prend l'argument iFormatProvider. Passer la cultureinfo.getcultureInfo ("EN-GB"). DateTimeFormat.
Merci pour vos réponses (Andy posta la question en mon nom). C'était en effet un problème avec les paramètres régionaux, mais ni avec l'utilisateur, je suis connecté en vertu de l'utilisateur, ni avec l'utilisateur, le processus était exécuté. Cela aurait été trop facile. On dirait que l'utilisateur par défaut était toujours en-nous. J'ai réinitialisé en cliquant sur la case à cocher "Appliquer les paramètres sur l'utilisateur actuel et l'utilisateur par défaut ..." dans l'onglet Avancé et redémarrez le serveur. System.globalization.CultureInfo Retournez maintenant {EN-GB}. Et un mydate.Tostring (aaaa-mm-dd) fonctionne correctement si la date est transmise en tant que DD / mm / aaaaa ou jj-mm-aaaa ou aaaa-mm-mm-dd sans la nécessité d'analyser.
Cependant, vous remerciez tous beaucoup pour vos suggestions (parseexact, etc.) qui fonctionnaient effectivement. Ils sont malheureux très utiles pour les autres formats de date que je n'ai pas pu gérer de manière agréable (yyyymmdd).
marc
Observation intéressante et précieuse sur les paramètres utilisateur par défaut
Il pourrait être intéressant de voir si le problème provient de l'environnement C ++ / COM ou du système d'exploitation. Et si vous venez simplement une application de console simple avec console.writeline (fil.currentThread.CurrentCulture.displa yname); Que montre-t-il?