fonction to_char appliquée à des dates

Bonjour,

Par défaut, oracle affiche les dates au format défini dans la variable d'environnement nls_ date_format.

Mais la fonction to_char permet de convertir ces dates en un autre format de notre choix.
Je voulais simplement confirmer que cette conversion n'entraîne pas le changement de format par défaut et que dans la base de données les dates sont toujours au format défini dans la variable d'environnement nls_date_format.

Merci beaucoup de votre aide.

Cordialement

Nathalie

je te le confirme ;)

Une date est stockée en base sans aucun format associé.
C'est seulement lors de l'affichage que l'on passe par un format défini par défaut dans la base ou dans la session.

Bonjour,

Si les données ne sont pas à un certain format dans la bdd, alors à quoi sert de donner un type de données lorsqu'on crée des champs?

D'après ce que je pense elles sont à un certain format date par défaut tel que défini dans la variable d'environnement nls_date_format et ensuite , si on veut modifier l'affichage en un aiutre format on peut le faire grace à la fonction to_char.

J'espère ne pas me tromper.

Cordialement.
Nathalie

La donnée a un type : DATE mais ce n'est pas formater... il faut comprendre que dans la base c'est probablement stocké comme un NUMBER (nombre de jour depuis une date fixée dans le noyau) qui a des propriétés particulières (voir les cours sur la programmation objet ;)). Le format d'affichage ne dépend donc que du contexte de l'application cliente qui sélectionne la donnée ;)

Merci de cette explication.J'en avais besoin.
Pourrais tu juste m'expliquer pourquoi, quand j'insère une donnée de type date dans la base de données, je dois mettre des simples quotes au niveau de la date saisie.
Pourrais tu également me confirmer que dans la base de données
les données de type date sont des nombres.
Merci encore à toi de ton aide.

Cordialement.
Nathalie

peu importe que ce soit inséré comme un nombre ou une chaine de caractères... t'as juste à savoir que le format (DD/MM/YYYY ou DD-MON-RR ou autre) est appliqué lors du SELECT.

Sinon, pourquoi des quotes... bah parce qu'il fallait bien trouver un moyen de montrer à la base où commence la date et ou elle se termine, c'est pour ça que la chaîne de caractères de la date est encadrée par des quotes.

Si tu as d'autres questions métaphysiques :mrgreen: n'hésite pas ;)

Une date est stocké dans la base dans un format de longueur fixe sur 7 octets (bytes); elle contient toujours: siècle, l'année dans le siècle, le mois, le jour du mois, l'heure, le minute et la seconde.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

create table t as select sysdate adate from dual / select adate, dump(adate, 10) from t   ADATE -------- DUMP(ADATE) ------------------------------------ 05/11/07 Typ=12 Len=7: 120,107,11,5,21,43,19

---

Le siècle et l'année sont stockée en notation en excès 100, cella veut dire qu'il faut extraire 100 pour déterminer la valeur. Le mois et le jour sont stockés sans modification. L'heure le minute et la seconde sont stockés en notation excès 1 (il faut soustraire 1)
Donc
120 – 100 = 20
107 – 100 = 7
21 – 1 = 20
43 – 1 = 42
19 -1 = 18
Cela fait 05 11 2007, 20 heure 42 minute et 18 seconde.

Code:

---

1 2 3 4 5 6 7 8 9

insert into t values ('06/11/2007');   SQL> select adate from t;   ADATE -------- 05/11/07 06/11/07

---

Le simple quotes il faut le mettre parce que ce tu insère est une chaîne de caractère. En fait le

Code:

---

1 2	insert into t values ('06/11/2007');

---

devient en fait

Code:

---

1 2	insert into t values (to_date('06/11/2007'))

---

sauf que c'est Oracle qui se charge de faire une conversion implicite chaîne de caractère vers date; mais se baser sur les conversions implicite est toujours mauvais :wink:

Merci de cette explication,
Mais si l'insertion est faite comme il se doit au bon format, la conversion implicite n'est pas utile, et les quotes qui entourent la date ne sont pas utiles non plus alors...
Merci de m'en dire plus à ce propos.
Cordialement.
Nathalie

Qu'est-ce que tu veux savoir exactement ? Parce que là tu t'arrêtes à des concepts tout à fait mineurs d'une importance tout à fait minime :?

Pour insérer une date sans conversion t'a pas d'autre moyen qu'utiliser une colonne ou variable de type date... une valeur en dur sera toujours une chaine de caractères

Commencez par vous dire « une date c’est une date, une date c’est une date, une date c’est une date, une date c’est n’est pas une chaîne de caractères, une chaîne de caractères n’est pas une date ». Répétez-le autant de fois que nécessaire pour que vous voyiez qu’il s’agit bien de deux types de données différentes.
Après il est simple a voir que les conversions s’applique en entrée/sortie et seulement quand on mélange les dates avec les chaînes de caractères. Exemple

Code:

---

1 2	Select sysdate from dual

---

renvoie un type de données date que on peut attribuer à une colonne de type date sans conversion. Par contre

Code:

---

1 2	Select ’01/01/2007’ from dual

---

renvoie un type de données chaîne de caractères qu'on ne peut pas attribuer à une colonne de type date que si on fait une conversion explicite ou malheureusement :cry: implicite.

Bonjour à tous,

Mon problème concerne un peu ce qui a été expliqué ici (je vous le soumets afin de voir si vous auriez par hasard une solution...) :

Dans une base Oracle, j'ai une table nommée "Evenement" , lquelle contient 2 champs :
- date_heure (enregistrée à l'heure GMT)
- titre (de l'évenement)

Chaque nouvel évenement est ainsi stocké en heure GMT

Le problème c'est que lorsque je les appelle, ces champs sont automatiquement traduits en heure locale.

Cela me pose un probleme de tri le jour du changement d'heure d'hiver vers heure d'été
-> le 28/10/07 à 3h00 il est 2h00, et donc on passe du GMT+2 au GMT+1 (et il y a donc 2 tranches 2h-3h en heure locale)

Si j'enregistre dans la base ces 2 évenements :
Evenement_1 au format GMT : 28/10/07 00:50 Sport
Evenement_2 au format GMT : 28/10/07 01:15 Musique

En heure locale ces dates_heures ont ces valeurs
Evenement_1 au format heure locale : 28/10/07 02:50 Sport
Evenement_2 au format heure locale : 28/10/07 02:15 Musique

Note : le changement d'heure a eu lieu entre ces 2 évenements

et donc lorsque je fais un select * from evenement order by date_heure ASC :

il me donne les evenement dans le mauvais ordre...
28/10/07 02:15 Musique
28/10/07 02:50 Sport

Comment faire pour que le tri se fasse bien sur l'heure enregistrée en base (GMT) et non retraduite en heure locale ???

Un grand merci pour votre aide...
Fred.

euh... y'a un truc que je ne saisis pas... en principe, GMT c'est GMT... y'a pas de changement d'heure si ?

Sinon, pour le tri tu peux ajouter une colonne pour stocker l'ordre d'insertion ou alors ajouter une condition pour ajouter une heure selon la date mais là ça parait un peu compliqué pour pas grand chose :?

Merci pour ta réponse,

en fait GMT c'est bien une heure fixe, mais "notre" changement d'heure "en heure locale (france)" implique que l'on passe du GMT+2 au GMT+1 tel jour à telle heure (cette année c'est le 28/10/07 à 01h00 GMT)

Effectivement en base j'ai stocké du GMT et j'aimerais le voir à l'écran !
le probleme est que tout "select" de date est traduit en heures locales...

Je ne sais pas comment sortir ce que j'ai vraiment en base, sans que mon client SQL n'interprete la date...?

c'est du coté du programme client qu'il faut agir dans ce cas :koi:

Bonjour,

Merci pour votre réponse... en fait, j'essaye (pour commencer) de retrouver mes date_heures au format GMT dans un client SQL (via une requete) , mais je n'y arrive pas... C'est toujours transformé en heure locale...

j'ai même essayé la fonction new_time, mais j'ai toujours du local...

en gros j'aimerais trouver un moyen d'afficher en SQL dans mon client les date_heure en GMT...

Si qqun a une idée!? Je le remercie par avance!
Fred,

il me semble que pour se faire il faut que le poste client soit en GMT... peut-être qu'une conversion TIMESTAMP avec un TIMEZONE adéquat ferait l'affaire mais j'avoue que je ne suis pas calé en la matière :?

Tiens, voila qui devrait t'intéresser : http://www.developpez.net/forums/sho...d.php?t=422151
notamment le set time_zone ;)