Discussion :

[sjachym]

Bonjour, j'essaye de vérifier strictement une date parsée selon un pattern, mais le résultat semble aléatoirement permissif.
Ci dessous les dates passées et leur retour de la fonction ci après.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
//		String dateDebut = "20070903205030";
// OK : Mon Sep 03 20:50:30 CEST 2007
// Normal, correspond à une vraie date

//		String dateDebut = "200709032050301";
// Erreur : Unparseable date: "200709032050301"
// Normal, date faussée avec le 1 en trop à la fin

		String dateDebut = "200709032050001";		
// OK : Mon Sep 03 20:50:01 CEST 2007
// ??? Anormal ! Un caractère en trop, et il semble ignorer les mutiples 0

		String dateDebut = "200708311829003";
// OK : Fri Aug 31 18:29:03 CEST 2007
// ??? Anormal ! Un caractère en trop, et il semble ignorer les mutiples 0
		
		DateFormat unFormat = new SimpleDateFormat("yyyyMMddHHmmss");
		unFormat.setLenient(false);
		Date dateFormatDebut = new Date();
		try {
			dateFormatDebut = unFormat.parse(dateDebut);
//			dateFormatFin = unFormat.parse(dateFin);
			System.out.println("OK : "+dateFormatDebut);
		} catch (ParseException e) {
			System.out.println("Erreur : " + e.getMessage());
		}

Un idée de ce qui provoque ce phénomène ? Les multiples 0 ? Comment vérifier la stricte égalité au pattern ?

[adiGuba]

Salut,


Dans un cas il prend "301" comme valeur pour les secondes, ce qui est trop grand d'où l'erreur...

Dans l'autre il prend "001" donc "1" ce qui est correct...



Tu pourrais peut-être vérifié la taille de la chaine avant de la parser. Non ?

a++

[sjachym]

Ok, je pensais contourner cela avec un Pattern.matcher ou en vérifiant la longueur de la chaine.
Mais sortant de développements PHP je suis surpris par le comportement de Java.... j'aurais penser qu'il fasse comme un ereg PHP avant sa conversion en Date.
En tout cas merci pour la réponse.