Bonjour,
 
J'ai un pb de date Oracle.
Je m'explique :  
. quand j'affiche ma date oracle, celle-ci est correcte  
. quand je soustrais cette date à la date du jour, j'obtiens un nombre de jour énorme, comme si la date stockée était en fait en l'année 6031
Ex : SELECT to_char(EV.BEGINDATE,'DD/MM/YYYY'), to_char(sysdate,'DD/MM/YYYY'), sysdate-ev.begindate diff
FROM affaires_test.PLANNINGEVENT ev
WHERE ID = 659117
13/02/2011 05/12/2011 1469317,72783565                        
 
Évidemment, dans la même table, des enregistrements sont justes, d'autres faux comme ce cas là.
 
Serveur Oracle 10.2.0.5.0 / Windows 2008 R2 standard 64 bits
 
Si quelqu'un a une idée...
Merci

Il faudrait faire un to_char() du résultat, sinon le résultat est exprimé en nombre de secondes ou de milli-secondes ou de quelque chose de ce genre.

Non la réponse est en jours.
Mais faire un to_char() va surement marcher quand meme.
 
Ca te dit quoi si tu fais:
SELECT EV.BEGINDATE
FROM affaires_test.PLANNINGEVENT ev
WHERE ID = 659117  

Ta date est le 13/02/-2011.
 
Le planning à donc commencé il y a plus de 4000 ans.
 
En effet, si sysdate - EV.BEGINDATE te donne 1469317,72783565, c'est que EV.BEGINDATE est situé 1469317,72783565 jours dans le passé, et non pas dans le futur en l'an 6031.
 
Et en effet,  select to_char(sysdate-1469317.72783565,'DD/MM/SYYYY') from dual donne 13/02/-2011.
 
Voir http://docs.oracle.com/cd/B19306_0 [...] htm#i34924 pour 'SYYYY'
 
C'est pas Oracle qui se plante, c'est le petit malin qui saisie la date !

Merci à tous et surtout merci Mara's dad !!!
je tournais en rond et ces 4000 d'écarts ne s'expliquaient pas mais dans le bon sens effectivement, ça explique pas mal de chose.
Dans le cas présent, je ne suis pas sûr que je vais mettre en cause le petit malin qui saisit la date sans avoir vérifier au préalable auprès de l'éditeur si il n'y a pas un bug applicatif car les updates sont de la forme update [...] set begindate=to_char('13/02/11','DD/MM/RR')