| Documentation PostgreSQL 7.4.29 | ||||
|---|---|---|---|---|
| Pr�c�dent | Arri�re rapide | Chapitre 8. Types de donn�es | Avance rapide | Suivant |
PostgreSQL supporte l'ensemble des types date et heure de SQL, montr�s dans Tableau 8-9.
Tableau 8-9. Types date et heure
| Nom | Taille de stockage | Description | Valeur minimale | Valeur maximale | R�solution |
|---|---|---|---|---|---|
| timestamp [ (p) ] [ without time zone ] | 8 octets | date et heure | 4713 avant JC | 5874897 apr�s JC | 1 microseconde / 14 chiffres |
| timestamp [ (p) ] with time zone | 8 octets | date et heure, avec fuseau horaire | 4713 avant JC | 5874897 apr�s JC | 1 microseconde / 14 chiffres |
| interval [ (p) ] | 12 octets | intervals de temps | -178000000 ann�es | 178000000 ann�es | 1 microseconde |
| date | 4 octets | dates seulement | 4713 avant JC | 32767 apr�s JC | 1 jour |
| time [ (p) ] [ without time zone ] | 8 octets | heures seulement | 00:00:00.00 | 23:59:59.99 | 1 microseconde |
| time [ (p) ] with time zone | 12 octets | heures seulement, avec fuseau horaire | 00:00:00.00+12 | 23:59:59.99-12 | 1 microseconde |
Note�: Avant PostgreSQL 7.3, �crire seulement timestamp �tait �quivalent � timestamp with time zone. Ceci a �t� chang� pour une meilleure compatibilit� avec le standard SQL.
time, timestamp, et interval acceptent une pr�cision optionnelle p, qui pr�cise le nombre de chiffres apr�s la virgule pour les secondes. Par d�faut, il n'y a pas de limite explicite � la pr�cision. Les valeurs accept�es pour p vont de 0 � 6 pour les types timestamp et interval.
Note�: When timestamp values are stored as double precision floating-point numbers (currently the default), the effective limit of precision may be less than 6. timestamp values are stored as seconds before or after midnight 2000-01-01. Microsecond precision is achieved for dates within a few years of 2000-01-01, but the precision degrades for dates further away. When timestamp values are stored as eight-byte integers (a compile-time option), microsecond precision is available over the full range of values. However eight-byte integer timestamps have a more limited range of dates than shown above: from 4713 BC up to 294276 AD.
Note�: Lorsque les valeurs de type timestamp sont stock�es comme des nombres � virgule flottante de pr�cision double (ce qui est le cas par d�faut), la limite de pr�cision effective peut �tre inf�rieure � 6. Les valeurs de timestamp sont stock�es comme des secondes depuis le avant ou apr�s minuit le 1er janvier 2001. La pr�cision de la milliseconde est atteinte pour quelques ann�es autour de cette date mais la pr�cision se d�grade si on s'en �loigne. Lorsque les valeurs de timestamp sont stock�s comme des entiers sur 8 octets, ce qui est une option � la compilation, la pr�cision de la microseconde est disponible sur tout l'intervalle des valeurs. N�anmoins, cet intervalle est encore plus limit� :: de 4713 avant J�sus Christ � 294276 apr�s J�sus Christ.
Note�: Avant PostgreSQL 7.3, indiquer juste timestamp �tait �quivalent � timestamp with time zone. Ce comportement a �t� chang� en respect du standard SQL.
Pour les types time, l'intervalle accept� pour p est de 0 � 6 lorsque les entiers sur 8 octets sont utilis�s, ou de 0 � 10 lorsque le stockage se fait sous forme de nombre � virgule flottante.
Le type time with time zone est d�fini dans le standard SQL, mais sa d�finition lui pr�te des propri�t�s qui font douter de son utilit�. Dans la plupart des cas, une combinaison de date, time, timestamp without time zone, et timestamp with time zone devrait permettre de r�soudre toutes les fonctionnalit�s de date et heure n�cessaires � une application.
Les types abstime et reltime sont des types de pr�cision moindre, utilis�s en interne. Il n'est pas recommand� de les utiliser dans de nouvelles applications. Au contraire, il est souhaitable de migrer l'existant vers un autre type appropri�. Ces types internes pourraient dispara�tre dans une future version.
La saisie de dates et heures et possible dans la plupart des formats raisonnables, dont ISO8601, compatible SQL, traditionnel POSTGRES, et d'autres. Pour certains formats, l'ordre des jours, mois et ann�es en entr�e est ambigu. Il est alors possible de pr�ciser l'ordre attendu pour ces champs. R�glez le param�tre datestyle � MDY pour choisir une interpr�tation mois-jour-ann�e, � DMY pour jour-mois-ann�e, � YMD pour ann�e-mois-jour.
PostgreSQL est plus flexible que la norme SQL ne l'exige pour la manipulation des dates et des heures. Voir Annexe B pour conna�tre les r�gles exactes de reconnaissance des dates et heures, ainsi que les formats de champs texte comme les mois, les jours de la semaine et les fuseaux horaires.
Rappelez vous que chaque litt�ral date ou heure � entrer doit �tre mis entre apostrophes, comme les cha�nes de caract�res. R�f�rez vous � Section 4.1.2.4 pour plus d'information. SQL requi�re la syntaxe suivante:
type [ (p) ] 'value'
o� p dans la sp�cification optionnelle de pr�cision est un entier correspondant au nombre de chiffres apr�s la virgule dans le champ secondes. La pr�cision peut �tre pr�cis�e pour les types time, timestamp, et interval. Les valeurs admissibles sont mentionn�es plus haut. Si aucune pr�cision n'est indiqu�e dans une sp�cification de constante, elle prend la pr�cision de la valeur litt�rale.
Tableau 8-10 montre les formats de date possibles pour les entr�es de type date.
Tableau 8-10. Saisie de date
| Exemple | Description |
|---|---|
| January 8, 1999 | sans ambigu�t� quel que soit le style de date (datestyle) |
| 1999-01-08 | ISO-8601; 8 janvier, quel que soit le mode (format recommand�) |
| 1/8/1999 | 8 janvier en mode MDYMDY; 1er Ao�t en mode DMY |
| 1/18/1999 | 18 janvier en mode MDY; rejet� dans les autres modes |
| 01/02/03 | 2 janvier 2003 en mode MDY; 1er f�vrier 2003 en mode DMY; 3 f�vrier 2003 en mode YMD |
| 1999-Jan-08 | 8 janvier dans tous les modes |
| Jan-08-1999 | 8 janvier dans tous les modes |
| 08-Jan-1999 | 8 janvier dans tous les modes |
| 99-Jan-08 | 8 janvier en mode YMD, erreur sinon |
| 08-Jan-99 | 8 janvier, sauf en mode YMD: erreur |
| Jan-08-99 | 8 janvier, sauf en mode YMD: erreur |
| 19990108 | ISO-8601; 8 janvier 1999 dans tous les modes |
| 990108 | ISO-8601; 8 janvier 1999 dans tous les modes |
| 1999.008 | Ann�e et jour dans l'ann�e |
| J2451187 | Jour du calendrier Julien |
| January 8, 99 BC | ann�e 99 avant J�sus Christ |
Les types heure-du-jour sont time [ (p) ] without time zone et time [ (p) ] with time zone. �crire juste time est �quivalent � time without time zone
Les valeurs d'entr�e valides pour ces types sont constitu�es d'une heure du jour suivi d'un fuseau horaire optionnel. (voir Tableau 8-11 et Tableau 8-12.) Si un fuseau est pr�cis� pour le type time without time zone, il est ignor� sans message d'erreur.
Tableau 8-11. Saisie d'heure
| Exemple | Description |
|---|---|
| 04:05:06.789 | ISO 8601 |
| 04:05:06 | ISO 8601 |
| 04:05 | ISO 8601 |
| 040506 | ISO 8601 |
| 04:05 AM | Identique � 04:05; AM n'affecte pas la valeur |
| 04:05 PM | Identique � 16:05; l'heure doit �tre <= 12 |
| 04:05:06.789-8 | ISO 8601 |
| 04:05:06-08:00 | ISO 8601 |
| 04:05-08:00 | ISO 8601 |
| 040506-08 | ISO 8601 |
| 04:05:06 PST | fuseau horaire pr�cis� en lettres |
Les valeurs d'entr�e valides sont constitu�es par la concat�nation d'une date, d'une heure, d'un qualificatif optionnel AD (avant J�sus Christ) ou BC (apr�s J�sus Christ), et d'un fuseau horaire optionnel. Ainsi:
1999-01-08 04:05:06
et
1999-01-08 04:05:06 -8:00
sont des valeurs valides, qui suivent le standard ISO 8601. De plus, le format
January 8 04:05:06 1999 PST
tr�s courant, est support�.
Pour timestamp [without time zone], un fuseau horaire explicite est ignor� sans message. C'est � dire que la date/heure r�sultante n'est pas ajust�e pour le fuseau horaire.
Pour timestamp with time zone, la valeur stock�e en interne est toujours en UTC (Temps Universel Coordonn�), aussi connu sous le nom de GMT. Les valeurs d'entr�e qui ont un fuseau horaire explicite sont converties en UTC en utilisant le d�calage appropri�. Si aucun fuseau horaire n'est pr�cis�, alors le syst�me consid�re que la date est dans le fuseau horaire indiqu� par le param�tre syst�me timezone, et la convertit en UTC en utilisant le d�calage de la zone timezone.
Quand une valeur timestamp with time zone est affich�e, elle est toujours convertie de UTC vers le fuseau horaire courant (variable timezone), et affich�e comme une heure locale de cette zone. Pour voir l'heure dans un autre fuseau horaire, il faut soit changer la valeur de timezone ou utiliser la construction AT TIME ZONE (voir Section 9.8.3).
Les conversions entre timestamp without time zone et timestamp with time zone consid�rent normalement que la valeur timestamp without time zone utilise le fuseau horaire timezone. Une zone diff�rente peut �tre choisie en utilisant AT TIME ZONE.
Les valeurs de type interval utilisent la syntaxe suivante:
[@] quantit� unit� [quantit� unit�...] [direction]
O�: quantit� est un nombre (�ventuellement sign�); unit� est second, minute, hour, day, week, month, year, decade, century, millennium, ou des abr�viations ou des pluriels de ces unit�s; direction peut �tre ago ou vide. L'arobase (@) est du bruit optionnel. Les valeurs des diff�rentes unit�s sont implicitement ajout�es en utilisant le signe appropri�.
Les quantit�s de jours, heures, minutes et secondes peuvent �tre pr�cis�es sans unit� explicite. Par exemple '1 12:59:10' est lu comme '1 day 12 hours 59 min 10 sec' (1 jour, 12 heures, 59 minutes, 10 secondes).
La pr�cision optionnelle doit �tre entre 0 et 6, et prend la pr�cision du litt�ral comme valeur par d�faut.
Les fonctions suivantes, compatibles SQL, sont utilisables comme des valeurs de date ou d'heure: CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, LOCALTIME, LOCALTIMESTAMP. Les 4 derni�res acceptent une sp�cification de pr�cision optionnelle. (voir aussi Section 9.8.4.)
PostgreSQL supporte aussi plusieurs valeurs de dates sp�ciales, par simplicit�, comme montr� dans Tableau 8-13. Les valeurs infinity et -infinity ont une repr�sentation sp�ciale dans le syst�me et seront affich�es de la m�me fa�on. Les autres sont simplement des facilit�s de notation qui seront converties en dates/heures ordinaires lorsqu'elles seront lues. Toutes ces valeurs sont trait�es comme des constantes normales, et doivent �tre �crites entre apostrophes.
Tableau 8-13. Saisie de dates/heures sp�ciales
| Cha�nes entr�es | Types valides | Description |
|---|---|---|
| epoch | date, timestamp | 1970-01-01 00:00:00+00 (date syst�me z�ro d'Unix) |
| infinity | timestamp | plus tard que toutes les autres dates |
| -infinity | timestamp | plus t�t que toutes les autres dates |
| now | date, time, timestamp | heure de d�but de la transaction courante |
| today | date, timestamp | minuit aujourd'hui |
| tomorrow | date, timestamp | minuit demain |
| yesterday | date, timestamp | minuit hier |
| allballs | ||
| allballs | time | 00:00:00.00 UTC |
Le format de sortie des types date/heure peut �tre choisi parmi un des quatre formats de date suivants: ISO 8601, SQL (Ingres), Traditionnel POSTGRES, et Allemand, en utilisant la commande SET datestyle. Le format par d�faut est le format ISO, comme demand� par le standard SQL. Le nom du format d'affichage <<�SQL�>> est un accident historique. Tableau 8-14 montre des exemples de chaque format d'affichage. Le format d'un type date ou time est bien sur celui de la partie date ou heure, comme montr� dans les exemples.
Tableau 8-14. Styles d'affichage de date/heure
| Sp�cification de style | Description | Exemple |
|---|---|---|
| ISO | standard ISO 8601/SQL | 1997-12-17 07:37:16-08 |
| SQL | style traditionnel | 12/17/1997 07:37:16.00 PST |
| POSTGRES | style original | Wed Dec 17 07:37:16 1997 PST |
| German | style r�gional | 17.12.1997 07:37:16.00 PST |
Dans les styles SQL et POSTGRES, les jours apparaissent avant le mois si l'ordre des champs DMY a �t� pr�cis�, sinon les mois apparaissent avant les jours. (Voir Section 8.5.1 pour savoir comment ce param�tre affecte l'interpr�tation des valeurs entr�es.) Tableau 8-15 montre un exemple.
Tableau 8-15. Convention d'ordre des dates
| R�glage de >datestyle (style de date) | Ordre d'entr�e | Exemple d'affichage |
|---|---|---|
| SQL, DMY | jour/mois/ann�e | 17/12/1997 15:37:16.00 CET |
| SQL, MDY | mois/jour/ann�e | 12/17/1997 07:37:16.00 PST |
| Postgres, DMY | jour/mois/ann�e | Wed 17 Dec 07:37:16 1997 PST |
L'affichage du type interval ressemble au format de saisie, sauf que les unit�s comme century ou week sont converties en ann�es et jours, et que ago est converti en un signe appropri�. En mode ISO, l'affichage ressemble �:
[ quantit� unit� [ ... ] ] [ jours ] [ heures:minutes:secondes ]
Les styles de date/heure peuvent �tre s�lectionn�s soit en utilisant la
commande SET datestyle, soit en utilisant le param�tre
datestyle du fichier de configuration
postgresql.conf, soit avec la variable
d'environnement PGDATESTYLE sur le serveur ou le client.
La fonction de formatage to_char (voir Section 9.7) permet aussi, de mani�re plus flexible,
pour formater les affichages de date/heure.
Les fuseaux horaires et les conventions d'heures sont influenc�es par des d�cisions politiques, pas seulement par la g�om�trie de la terre. Les fuseaux horaires se sont un peu standardis�s au cours du vingti�me si�cle, mais continuent d'�tre soumis � des changements arbitraires. PostgreSQL utilise les fonctionnalit�s de votre syst�me d'exploitation pour proposer le support des fuseaux horaires. Souvent, ces syst�mes ne contiennent les informations que pour la p�riode qui va de 1902 � 2038 (ce qui correspond � l'�tendue compl�te des dates syst�me conventionnelles d'Unix). timestamp with time zone et time with time zone n'utilisent les informations de fuseaux horaires que dans cette p�riode, et utilisent l'heure UTC pour les autres dates. Mais comme le support des fuseaux horaires est issu de celui du syst�me d'exploitation, il peut supporter les heures d'�t� et autres comportements particuliers.
PostgreSQL se veut compatible avec les d�finitions standard SQL pour un usage typique. N�anmoins, le standard SQL poss�de un m�lange bizarre de types de date/heure et de possibilit�s. Deux probl�mes sont �vidents:
Bien que le type date n'ait pas de fuseau horaire associ�, le type heure peut en avoir un. Les fuseaux horaires, dans le monde r�el, ne peuvent avoir de sens qu'associ�s � une date et � une heure, vu que l'�cart peut varier avec l'heure d'�t�.
Le fuseau horaire par d�faut est pr�cis� comme un �cart num�rique constant avec l'UTC. Il n'est pas possible de s'adapter � l'heure d'�t� ou d'hiver lorsque l'on fait des calculs arithm�tiques qui passent les limites de l'heure d'�t� et l'heure d'hiver.
Pour ne pas avoir ces difficult�s, nous recommandons d'utiliser des types de date/heure qui contiennent � la fois une date et une heure lorsque vous utilisez les fuseaux horaires. Nous recommandons de ne pas utiliser le type time with time zone. Ce type est n�anmoins propos� par PostgreSQL pour les applications existantes et pour assurer la compatibilit� avec les autres bases de donn�es compatibles SQL. PostgreSQL utilise votre fuseau horaire pour tous les types qui ne contiennent qu'une date ou une heure.
Toutes les dates et heures sont stock�es en interne en UTC. Les heures sont converties en heure locale sur le serveur de bases de donn�es avant d'�tre envoy�es au client, et sont donc par d�faut dans le fuseau horaire du serveur.
Il y a plusieurs fa�ons de choisir le fuseau horaire utilis� par le serveur:
La variable d'environnement TZ du serveur h�te est utilis�e par le serveur de bases de donn�es comme fuseau horaire par d�faut, si aucune autre n'est pr�cis�e.
Le param�tre de configuration timezone peut �tre indiqu� dans le fichier postgresql.conf.
La variable d'environnement PGTZ, si elle est mise � jour par le client, est utilis�e par les applications bas�es sur libpq pour envoyer une commande SET TIME ZONE au serveur lors de la connexion.
La commande SQL SET TIME ZONE permet de choisir le fuseau horaire pour la session.
Note�: Si un fuseau horaire invalide est indiqu�, le fuseau horaire devient UTC (sur la plupart des syst�mes).
Voir Annexe B pour avoir une liste des fuseaux horaires disponibles.
PostgreSQL utilise les dates Juliennes pour tous les calculs de date/heure. Elles ont la propri�t� int�ressante de permettre le calcul de toute date entre 4713 avant J�sus Christ et loin dans le futur, si on utilise le fait que l'ann�e dure 365,2425 jours.
Les conventions de date ant�rieures au 19�me si�cle offrent une lecture int�ressante, mais ne sont pas assez consistantes pour �tre cod�es dans un gestionnaire de dates.
| Pr�c�dent | Sommaire | Suivant |
| Types de donn�es binaires | Niveau sup�rieur | Type Boolean |