Discussion :

[erox44]

Salut,

j'ai le bout de code suivant :

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
27
28
				Statement stmt2 = conn.createStatement();
//				Statement stmt2 = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_UPDATABLE);
				stmt2.setFetchSize(1000);
				ResultSet rs2 = stmt2.executeQuery(sql);
///				Source.progression = 50;
//				rs2.last();
//				int total = rs2.getRow();
//				int traite = 0;
//				rs2.beforeFirst();
				ResultSetMetaData meta = rs2.getMetaData();
				logger.debug("debut fetch");
				while(rs2.next()){
 
					String strDatePublish = rs2.getString(1);
 
					// on parse notre string pour virer les millisecondes
					SimpleDateFormat parser = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SS");
					Date datePublish = parser.parse(strDatePublish);
					SimpleDateFormat formater = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss");
					strDatePublish = formater.format(datePublish);
 
					// creation du bean 
					..
//					Source.progression = 50+(traite*30)/total; 
//					traite++;
				}
				rs2.close();
				stmt2.close();

Entre le code actuel et le code commenté l'exécution plante au niveau de :

Code :

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

SimpleDateFormat parser = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SS");

Dans le code actuel, la date récupérée est de la forme:

Code :

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

2014-12-01 12:00:00:000

Et avec l'autre version dans laquelle je passe mon résultset en ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_UPDATABLE :

Code :

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

1/11/2014 17:3:11

Ce comportement est-il normal ? :o

[OButterlin]

C'est surprenant...
Mais ce qui me surprend d'avantage c'est ta base de données... Le traitement que tu expliques laisse sous-entendre que tu as défini la colonne représentant un horodatage en CHAR ou VARCHAR plutôt que DATETIME ou TIMESTAMP

Bref, la logique voudrait que tu ais une colonne TIMESTAMP et que tu fasses dans ta lecture un rs2.getTimestamp(1)

[Alkhan]

bonjour,

Le traitement que tu expliques laisse sous-entendre que tu as défini la colonne représentant un horodatage en CHAR ou VARCHAR plutôt que DATETIME ou TIMESTAMP

Moi je serais tenté de dire que dans la base il y a bien une date, mais vu qu'il demande un chaine le driver fait ce qu'il peux pour lui en retourner une !

[OButterlin]

bonjour,

Moi je serais tenté de dire que dans la base il y a bien une date, mais vu qu'il demande un chaine le driver fait ce qu'il peut pour lui en retourner une !

C'est possible... mais c'est d'autant plus dommage

[erox44]

En Base , la colonne en question est bien définie en DATE.

Le truc c'est que si je fais un :

Code :

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

java.sql.Date strDatePublish = rs2.getDate(1);

Il me retourne une date avec les heures, minutes et secondes à 0 systématiquement.

C'est pour ça que j'utilise le getString que je formatte ensuite.

[OButterlin]

C'est normal, java.sql.Date n'est qu'une date, par une date/heure.
Utilise un Timestamp pour ça (en base de données aussi)

[Alkhan]

Il me retourne une date avec les heures, minutes et secondes à 0 systématiquement.

C'est pour ça que j'utilise le getString que je formatte ensuite.

Si dans la base ce qui est stocké est juste la date alors, n'espère pas avoir les heures, minutes et secondes avec une valeur autre que 0.
Tu aura toujours ce résultat et ce quelque soit la technique pour récupérer l'information.

Je rejoint donc OButterlin pour dire que si tu veux récupérer une date/heure il faut alors que tu changes le type de champs dans la base.

[erox44]

Malheureusement la structure de la table ne peut être modifiée :p

Après effectivement, en récupérant un timestamp, ça fonctionne bien, du coup je vais partir là dessus.

Je pensais que le getTimestamp renvoyait forcement notre date avec le fuseau à la fin.


Merci.

[tchize_]

Moi je serais tenté de dire que dans la base il y a bien une date, mais vu qu'il demande un chaine le driver fait ce qu'il peux pour lui en retourner une !

Hooo, le beau double sens. Et je suis sur que le driver en voyant ça meurt d'envie de lui en retourner une


Pour le reste:

getTimestamp => renvoie date + heure dans un objet de type Timestamp, qui étends java.util.Date. C'est une "date" java à part entière
getDate => renvoie une date avec l'heure mise à zéro. C'est un objet de type java.sql.Date qui étends java.util.Date. Sa particularité, c'est les champs à 0
getTime => renvoie une heure. C'est un objet de type java.sql.Time qui étends java.util.Date. Sa particularité est que le jour est placé au 1er janvier 1970

Si la base de données a été configurée avec des Colonnes incluant aussi la timezone, elle sera prise en compte pour que l'objet Date soit correct. Sinon il existe des méthode alternative prenant un objet de type Calendar pour forcer une timezone, ou ça utilisera la timezone par défaut.

A noter que le résultat final est indépendant de la timeZone. En effent ni java.util.Date, ni aucun descendant n'a de notion de timezone. Ils stockent juste un long représentant le nombre de millisecondes depuis EPOCH dans la zone GMT.