Bonjour,
 
voilà j'ai un petit problème avec les dates. J'utilise dans une page JSP les deux lignes suivantes :
 
Locale iLoc = request.getLocale();
DateFormat iDf = DateFormat.getDateInstance(DateFormat.SHORT,iLoc);
 
J'obtiens le plus souvent avec ces lignes une locale françaises et donc le format de date suivant : JJ/MM/AA or, je préférerai avoir les dates formater avec quatres chiffres pour l'année --> JJ/MM/AAAA
 
Comment puis-je m'y prendre ?

tu prend un autre DateFormat que le .SHORT ou bien t'utilises SimpleDateFormat, mais dans ce cas tu oublies la locale
 
sinon tu peux redefinir ton format pour toutes les locales

Bon j'ai opté pour le SimpleDateFormat, et j'ai donc
 
DateFormat iDf = new SimpleDateFormat(TConstant.szDATEFORMAT);
 
où TConstant.szDATEFORMAT = "dd/MM/yyyy"
 
(désolé pour les conventions des noms de variables et autres, mais je dois respecté une norme interne à l'entreprise)
 
et donc, maintenant, je voudrait être sur que l'utilisateur saisissent bien une date avec ce format, et éviter les saisies du type dd/MM/yy, que l'utilisateur semble toujours pouvoir faire malgré ce format...

1/ Tu as conscience que tu n'as plus aucune dépandance avec la locale du client (en d'autres termes le format sera toujours jj/mm/AAAA)
 
2/ Pour vérifier que le format est correct, il te suffit de parser l'input du client et catcher une éventuelle java.text.ParseException (c'est une exception un peu spéciale qui te donne l'offset où l'erreur à lieu dans la string que tu lui passes en paramètre

1/ Oui j'en ai conscience, mais il me suffit de faire (dans une evolution future), à la place d'une constante chaîne, un tableau de constante du genre
 
public final String[] tszDATEFORMAT = {"dd/MM/yyyy","MM/dd/yyyy"};
 
et en fonction de la locale de l'utilisateur, je prends la 1° ou la 2° valeurs de ce tableau
 
2/ et ben non...
 
DateFormat iDf = new SimpleDateFormat(TConstant.szDATEFORMAT);
(szDATEFORMAT = "dd/MM/yyyy" )
 
try
{
 iDf.parse(tszVal1[nCnt]);
}
catch (ParseException iExp)
{
 return "&errordate=" + tszCriIdx[nCnt];
}
 
où tszVal1[nCnt] = 02/02/02;
 
l'exception n'est pas lancer...

effectivement. Le parse arrive à s'en sortir avec ce format là. 2 secondes je regarde

et c'est même pire
 

 
ca me renvoie:
 

 
donc il prendr le 01/01/0001

C koi comme type d'appli ? soft ? web ? autres ?

Ben, j'ai fait un truc un peu salle mais ça marche...
 
if (tszVal[nCnt].length() == TConstant.szDATEFORMAT.length())
{  
 try
 {
  iDf.parse(tszVal[nCnt]);
 }
 catch (ParseException iExp)
 {
  return "&errordate=" + tszFldIdx[nCnt];
 }
}
else
{
 return "&errordate=" + tszFldIdx[nCnt];
}
 
donc c'est bon... Merci quand même

Pour info à Liengy
 
c'est du Web, page JSP...

Alors pkoi tu te contentes pas d'un controle javascript ?

Rien n'empêche le client de désactiver le Javascript...

j'allais te proposer de vérifier la taille de la chaine (10 caractères et pas 8 dans le cas d'une année en yy). Mais bon je suppose que c'est ce que ton code fait
 
Pour info si tu veux du parsing strict tu peux faire setLenient(false).
 
Ca évites des cas du genre
 
01/13/2002 -> 01/01/2003 (le 13eme mois shift et augmente l'année de 1).

ok merci du tuyau

Au fait, pourquoi pas de JavaScript...
 
En cas d'erreur de date, je rajoute en haut de la page un message :
Les dates doivent être saisies sous le format suivant : 14/08/2003
 
plus, je change la couleur du libellé du champ qui fait l'erreur...Et faire ça en JS, c'est un poil chaud, surtout quand on veut être compatible avec plusieurs navigateurs...

bah c'est pas une raison, c'est totozifiant quand meme

C'est vrai, mais bon, il n'a pas le choix. Au moins il y a une convention de codage.

euh ouais euh ....
http://java.sun.com/docs/codeconv/ [...] C.doc.html
 

Ben c'est une convention comme une autre, même si c'est celle recommandée à tous. Après tout l'important est de garder le style de codage uniforme pour les développeurs de sa boîte. Sinon il est mieux placé que moi pour l'expliquer.

Effectivement, j'utilise cette convention car je suis le seul de l'entreprise en coder en Java (chui stagière en fait). Les devellopeurs d'ici code pour la plupart en Delphi...
 
Précisions
 
sz : une chaîne
t: un tableau
--> tsz : un tableau de chaine
n : un entier
i : une instance de classe (forcément en Java tout est classe )
 
allez pour voir ce qui suivent : un tableau d'entier ?
 

 
?