Bonjour,
Une webmethod de mon webservice prend un parametre de type string
repr=E9sentant une date (sens=E9 repr=E9senter une date). De cette
mani=E8re, le user est libre de saisir une date selon le format qui lui
plait.
en gros, =E7a donne GetPrice("31/12/2005") ou GetPrice("31/12/05"),
etc...
Manque de bol, =E7a me pause un probl=E8me d'ambiguit=E9 selon les
param=E8tres regionaux du client.
Si le user saisie 1/5/05. Selon qu'il se trouve en M/d/yy ou d/M/yy,
l'interpretation est compl=E9tement diff=E9rente.
Je bataille avec les Date.Parse et autre CultureInfo de mes threads
mais sans succ=E8s !
Personne n'aurait une fonction "universelle" de conversion ?
Ou un moyen de d=E9terminer le format de date du user son sa saisie et
ses param regionaux...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Hervé HERRY
Bonjour Franck,
Ta question va peut-être bientôt me concerner également, aussi j'ai consulté ma référence récemment achetée : "C# et .NET" 2e édition de Gérard LEBLANC (Eyrolles). Il semble qu'il existe déjà un parser capable de prendre en compte la culture pour interpréter la date saisie par l'utilisateur :
using System; using System.Globalization;
string s = "14/7/1789"; DateTime dt = DateTime.Parse( s );
Ce bout de code ne fonctionnera que dans les pays francophones car Parse prend en compte la culture du pays dans lequel il est exécuté. Ailleurs, ce code génèrera une exception. Toutefois, si la chaîne 's' est saisie par l'utilisateur, c'est à priori ce que tu recherches.
Dans le cas de dates saisies "en dur" dans ton code, il faut préciser au parser selon quelle culture la chaîne a été saisie :
string s = "14/7/1789"; DateTime dt = DateTime.Parse( s, new CultureInfo("fr-FR"));
Ensuite, pour éviter toute ambiguïté, je pense qu'il est mieux d'informer l'utilisateur du format de saisie attendu en tenant compte toujours de la culture :
Ci-dessous le lien de la classe DateTimeFormatInfo retournée par la propriété DateTimeFormat du précédent exemple : http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/cpref/html/frlrfsystemglobalizationdatetimeformatinfoclasstopic.asp
En espérant que ça t'aideras. Tiens-moi au courant si ça fonctionne ! ;-)
-- Hervé HERRY Ingénieur R&D ACTARIS metering systems
"Franck" a écrit dans le message de news: Bonjour, Une webmethod de mon webservice prend un parametre de type string représentant une date (sensé représenter une date). De cette manière, le user est libre de saisir une date selon le format qui lui plait.
en gros, ça donne GetPrice("31/12/2005") ou GetPrice("31/12/05"), etc...
Manque de bol, ça me pause un problème d'ambiguité selon les paramètres regionaux du client.
Si le user saisie 1/5/05. Selon qu'il se trouve en M/d/yy ou d/M/yy, l'interpretation est complétement différente.
Je bataille avec les Date.Parse et autre CultureInfo de mes threads mais sans succès !
Personne n'aurait une fonction "universelle" de conversion ? Ou un moyen de déterminer le format de date du user son sa saisie et ses param regionaux...
Enfin voila.
merci de votre aide.
Bonjour Franck,
Ta question va peut-être bientôt me concerner également, aussi j'ai consulté
ma référence récemment achetée : "C# et .NET" 2e édition de Gérard LEBLANC
(Eyrolles). Il semble qu'il existe déjà un parser capable de prendre en
compte la culture pour interpréter la date saisie par l'utilisateur :
using System;
using System.Globalization;
string s = "14/7/1789";
DateTime dt = DateTime.Parse( s );
Ce bout de code ne fonctionnera que dans les pays francophones car Parse
prend en compte la culture du pays dans lequel il est exécuté. Ailleurs, ce
code génèrera une exception. Toutefois, si la chaîne 's' est saisie par
l'utilisateur, c'est à priori ce que tu recherches.
Dans le cas de dates saisies "en dur" dans ton code, il faut préciser au
parser selon quelle culture la chaîne a été saisie :
string s = "14/7/1789";
DateTime dt = DateTime.Parse( s, new CultureInfo("fr-FR"));
Ensuite, pour éviter toute ambiguïté, je pense qu'il est mieux d'informer
l'utilisateur du format de saisie attendu en tenant compte toujours de la
culture :
Ci-dessous le lien de la classe DateTimeFormatInfo retournée par la
propriété DateTimeFormat du précédent exemple :
http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/cpref/html/frlrfsystemglobalizationdatetimeformatinfoclasstopic.asp
En espérant que ça t'aideras.
Tiens-moi au courant si ça fonctionne ! ;-)
--
Hervé HERRY
Ingénieur R&D
ACTARIS metering systems
"Franck" <wesley.saris@gmail.com> a écrit dans le message de
news:1114585218.018490.134290@f14g2000cwb.googlegroups.com...
Bonjour,
Une webmethod de mon webservice prend un parametre de type string
représentant une date (sensé représenter une date). De cette
manière, le user est libre de saisir une date selon le format qui lui
plait.
en gros, ça donne GetPrice("31/12/2005") ou GetPrice("31/12/05"),
etc...
Manque de bol, ça me pause un problème d'ambiguité selon les
paramètres regionaux du client.
Si le user saisie 1/5/05. Selon qu'il se trouve en M/d/yy ou d/M/yy,
l'interpretation est complétement différente.
Je bataille avec les Date.Parse et autre CultureInfo de mes threads
mais sans succès !
Personne n'aurait une fonction "universelle" de conversion ?
Ou un moyen de déterminer le format de date du user son sa saisie et
ses param regionaux...
Ta question va peut-être bientôt me concerner également, aussi j'ai consulté ma référence récemment achetée : "C# et .NET" 2e édition de Gérard LEBLANC (Eyrolles). Il semble qu'il existe déjà un parser capable de prendre en compte la culture pour interpréter la date saisie par l'utilisateur :
using System; using System.Globalization;
string s = "14/7/1789"; DateTime dt = DateTime.Parse( s );
Ce bout de code ne fonctionnera que dans les pays francophones car Parse prend en compte la culture du pays dans lequel il est exécuté. Ailleurs, ce code génèrera une exception. Toutefois, si la chaîne 's' est saisie par l'utilisateur, c'est à priori ce que tu recherches.
Dans le cas de dates saisies "en dur" dans ton code, il faut préciser au parser selon quelle culture la chaîne a été saisie :
string s = "14/7/1789"; DateTime dt = DateTime.Parse( s, new CultureInfo("fr-FR"));
Ensuite, pour éviter toute ambiguïté, je pense qu'il est mieux d'informer l'utilisateur du format de saisie attendu en tenant compte toujours de la culture :
Ci-dessous le lien de la classe DateTimeFormatInfo retournée par la propriété DateTimeFormat du précédent exemple : http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/cpref/html/frlrfsystemglobalizationdatetimeformatinfoclasstopic.asp
En espérant que ça t'aideras. Tiens-moi au courant si ça fonctionne ! ;-)
-- Hervé HERRY Ingénieur R&D ACTARIS metering systems
"Franck" a écrit dans le message de news: Bonjour, Une webmethod de mon webservice prend un parametre de type string représentant une date (sensé représenter une date). De cette manière, le user est libre de saisir une date selon le format qui lui plait.
en gros, ça donne GetPrice("31/12/2005") ou GetPrice("31/12/05"), etc...
Manque de bol, ça me pause un problème d'ambiguité selon les paramètres regionaux du client.
Si le user saisie 1/5/05. Selon qu'il se trouve en M/d/yy ou d/M/yy, l'interpretation est complétement différente.
Je bataille avec les Date.Parse et autre CultureInfo de mes threads mais sans succès !
Personne n'aurait une fonction "universelle" de conversion ? Ou un moyen de déterminer le format de date du user son sa saisie et ses param regionaux...
Enfin voila.
merci de votre aide.
Roman
"Hervé HERRY" a écrit :
Ensuite, pour éviter toute ambiguïté, je pense qu'il est mieux d'informer l'utilisateur du format de saisie attendu en tenant compte toujours de la culture :
Je suis d'accord avec Hervé, il vaut mieux mettre des restrictions pour la saisie de date, sinon vous risquez d'avoir une usine à gaz et une source de bugs supplémentaire :)
"Hervé HERRY" a écrit :
Ensuite, pour éviter toute ambiguïté, je pense qu'il est mieux d'informer
l'utilisateur du format de saisie attendu en tenant compte toujours de la
culture :
Je suis d'accord avec Hervé, il vaut mieux mettre des restrictions pour la
saisie
de date, sinon vous risquez d'avoir une usine à gaz et une source de bugs
supplémentaire :)
Ensuite, pour éviter toute ambiguïté, je pense qu'il est mieux d'informer l'utilisateur du format de saisie attendu en tenant compte toujours de la culture :
Je suis d'accord avec Hervé, il vaut mieux mettre des restrictions pour la saisie de date, sinon vous risquez d'avoir une usine à gaz et une source de bugs supplémentaire :)
