Discussion :

[arnauann]

Bonjour,

J'ai besoin dans une fonction PL/SQL de savoir si on est en heure d'été ou en heure d'hivers, existe t-il une fonction qui permet de determiner avec PL/SQL ou Oracle?
Merci pour votre aide

[plaineR]

Pas à ma connaissance, mais il suffit de tester si tu es entre le dernier dimanche de mars et le dernier dimanche d'octobre.

[LeoAnderson]

Une date ? ou un TIMESTAMP WITH LOCAL TIME ZONE ?

http://www.dbasupport.com/oracle/ora9i/TimeZone.shtml

[edit]donc, oui, c'est possible !

Code :

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

select SESSIONTIMEZONE from dual;

par contre, cela nécessite de configurer configurer correctement la base, et après, on saura déterminer l'offset avec le GMT
[/edit]

[edit #2]
A ce sujet, quand vous développez, n'utilisez SYSDATE que si vous voulez réellement l'heure locale où se trouve votre serveur; si vous voulez avoir l'heure (locale), utilisez CURRENT_DATE.
Vous ne savez pas si votre appli ne sera pas déployée sur un serveur au Japon, ou si tout simplement pour éviter les problèmes de changements d'heures, tous les serveurs sont bloqués sur l'heurre GMT.

Ou si votre appli ne sera pas déployée partout dans le monde... (et la gestion des heures sup' en heures de Singapour pour un salarié en France, ça le fera moyen).

Il suffit d'utiliser les outils qu'Oracle met à disposition !

Note metalink 149118.1
[/edit #2]

[arnauann]

Merci bien pour votre aide, c'est ce que je cherchais.

[plaineR]

Intéressant.

Leo, peux-tu développer le sessiontimezone, il me ramène systèmatiquement 0. De plus je ne vois pas comment obtenir pour une date stockée dans la base si je suis en heure d'hiver ou d'été à partir de cette info.

Petite précision quant au current_date, il n'est dispo qu'à partir de la 9i.

[LeoAnderson]

Pour commencer, tout ceci n'est valable qu'à partir de la 9i et nécessite d'utiliser des TIMESTAMP en lieu et place des DATE.

Dans l'exemple ci-dessous, on a :

• La base dans le fuseau GMT
• L'utilisateur (OS) "leo" à GMT+2
• L'utilisateur (OS) "anderson" à GMT-7
• Un seul utilisateur (oracle) "leo" mais on pourrait en avoir plusieurs, ça changerait rien.

Je définis ma DB comme étant à l'heure GMT (C'est ce qu'il y a de plus simple pour tout le monde, GMT étant la référence; mais ça marche aussi avec un offset de -6h).
Soit je le fais à la création, soit après.

Code :

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

1
2
3
4
5
6
7
8
9
SQL> ALTER DATABASE SET TIME_ZONE='00:00';
 
Database altered.
 
SQL> SELECT dbtimezone FROM DUAL;
 
DBTIME
------
+00:00

Mon utilisateur OS leo a dans son .profile un positionnement permanent à GMT+2 :

Code :

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

export ORA_SDTZ='+02:00'

Code :

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

SQL> create table leo.test_tz (col timestamp with local time zone, col2 timestamp with time zone, col3 date);

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
SQL> insert into leo.test_tz (col, col2, col3)
  2  values (current_date, current_date, sysdate);
 
1 row created. 
 
SQL> select * from test_tz;
 
COL
---------------------------------------------------------------------------
COL2
---------------------------------------------------------------------------
COL3
-------------------
18-APR-07 06.24.02.000000 PM
18-APR-07 06.24.02.000000 PM +02:00
18/04/2007 18:24:02

on commence déjà à voir la différence entre with time zone et with local time zone !


prenons maintenant mon utilisateur Anderson à New-York (GMT-7)

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
[anderson@localhost ~]$ export ORA_SDTZ='-07:00'
[anderson@localhost ~]$ sqlplus leo
 
SQL*Plus: Release 10.2.0.1.0 - Production on Wed Apr 18 18:28:02 2007
 
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
 
Enter password: 
 
Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
 
SQL> select sessiontimezone from dual;
 
SESSIONTIMEZONE
---------------------------------------------------------------------------
-07:00

quelles sont les donnée qu'il voit dans la table test_tz :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
SQL> select * from test_tz;
 
COL
---------------------------------------------------------------------------
COL2
---------------------------------------------------------------------------
COL3
-------------------
18-APR-07 09.24.02.000000 AM
18-APR-07 06.24.02.000000 PM +02:00
18/04/2007 18:24:02

Donc le WITH TIME ZONE donne l'heure pour la personne qui fait l'opération et ce, quel que soit le fuseau horaire initial
WITH LOCAL TIME ZONE, c'est l'heure locale + le fuseau horaire ce qui permet d'en déduire l'heure locale correpondant à un autre endroit du globe
et une date, on n'a pas la notion de fuseau horaire et donc on mélange des heures "JAPON" avec des heures "FRANCE" ! :-S

Donc, je concluerais en disant que cette histoire de TZ est très importante car c'est une puissance et une souplesse totale mais qu'elle est malheureusement pas assez utilisée car peu de développeurs la connaissent.

Toute la doc : http://download-uk.oracle.com/docs/c....htm#sthref531

[edit]
Pour en revenir à la question initiale de changement d'heure été/hiver, Oracle intègre parfaitement (*) ça. (cf § Support for Daylight Saving Time)

(*) Enfin, quand il n'y a pas de bug dans les algos Sun ni que Bush ne change la date de changement d'heure !
http://www.oracle.com/technology/pub...ate-guide.html

Donc, oui, ça complexifie forcément un peu le dév. mais ça peut vous éviter de devoir réécrire toute votre application parce que le serveur sera déployer au siège social, c'est à dire San Fransisco !
[/edit]

[plaineR]

Très intéressant. Merci Leo pour cette explication très claire et très bien illustrée.

[francky74]

Bonjour,

A propos des explications de Léo Anderson au sujet du SESSIONTIMEZONE, Lorsque il y a inscrit SQL> avant la ligne de code, cela signifie-t-il que ce code est tapé dans SQLplus ?

Merci beaucoup,